|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: portal group is a component of ___?
Andre,
The network portals are components of the network entity (these are
possibly shared resources). The portal groups are components of the iSCSI
Node. One portal group for one iSCSI Node may span an overlapping but
non-equal set of network portals as another portal group for a different
iSCSI Node within the same network entity. In effect, the portal groups
are possibly logical constructs within a node. This is implied by the
current language of the model because session coordination is a function of
an iSCSI node and portal groups are collections of network portals over
which the session coordinator can handle multi-connection sessions. BUT, I
agree that your words:
A Portal Group is a component of an iSCSI node that defines a set of
Network Portals that collectively supports the capability of
coordinating a session with connections spanning these portals.
make this more clear.
Julo? Can you make this change (in the definition of Portal Groups in the
model clause)?
In your note attached, you respond to my first comment with "you mean
portal groups, not targets". No, I meant targets! One named "bar" and one
named "foobar". They share the same network portal. Each may have a
different view of how they lay portal groups across the shared (or not
shared) network portals. But I think we have this straight now.
In the previous thread, and concurred by John Hufferd, I've already made
the claim that the draft is ambiguous about the TargetName use -- and have
advocated clarification of the language.
As for redrawing the picture... It is very difficult in ASCII to draw a
picture that shows the complexity of possible ways of putting all these
pieces together. It's even difficult (as John will attest) to put them in
a fancy graphics picture. Also, the intent of the drawing is to
encapsulate what ONE target sees. Perhaps your change that the network
portals are "attached to" but not "contained in" portal groups is better
and more consistent with the first picture in the model clause. I have no
objection to this change either. (Julo?).
Thanks for the contributions!
Jim Hafner
Andre Asselin
11/02/2001 01:36 pm
To: Jim Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: portal group is a component of ___? (Document link: Database
'Jim Hafner', View '($Inbox)')
Jim,
First, let me say thanks-- this thread has educated me immensly on
some of the subtle aspects of iSCSI.
>Your picture isn't quite right. The portal group tag is relative to the
iSCSI target and that target is *uniquely* identified by it's name. So, in
your picture, there are two targets (not one).
<aa> I think you mean portal groups, not targets. </aa>
>Each can label its target portal group any way it wants (independent of
the other). Each has independent control over the TSIDs it uses. Each may
*share* use of a network portal, but that's a different issue. The model
implies two independent targets (even if they live in the same network
entity and share resources) in your scenario.
In other words, the portal groups are wrt targets not the network entity.
<aa>Thanks for the clarification-- I was missing this understanding of the
architecture. </aa>
> In your scenario, whatever layer (you put it in the network code) has to
decide what session to add the connection to has the initiator name, the
ISID, the TSID *and* the target name (you left this out) in the login
request. That fully qualifies both the target and the session as well.
<aa> I concur that that is how a target * should * identify a session,
however, that's not what the spec currently says, and needs to be updated.
Now, if you can put up with one more question, is a network portal a
component of a network entity or an iSCSI node? 2.5.1 (c) says its a
component of a network entity, but 2.5.1(d) says
A Portal Group defines a set of Network Portals within an iSCSI Node
that collectively supports the capability of coordinating a session
with connections spanning these portals.
which is kind of ambiguous as to whether it means portal group is within an
iSCSI node, or the network portals are within the iSCSI node. I'd suggest
this to clarify it:
A Portal Group is a component of an iSCSI node that defines a set of
Network Portals that collectively supports the capability of
coordinating a session with connections spanning these portals.
Also if a network portal really is a component of a network entity,
shouldn't the diagram on the following page be redrawn?
(original)
----------------------------IP Network---------------------
| | |
+--------|---------------|--------------------|---------------------+
| +----|---------------|-----+ +----|---------+
|
| | +---------+ +---------+ | | +---------+ |
|
| | | Network | | Network | | | | Network | |
|
| | | Portal | | Portal | | | | Portal | |
|
| | +--|------+ +---------+ | | +---------+ |
|
| | | | | | | |
|
| | | Portal | | | | Portal |
|
| | | Group 1 | | | | Group 2 |
|
| +--------------------------+ +--------------+
|
| | | |
|
| +----------------------------+ +-----------------------------+
|
| | iSCSI Session (Target side)| | iSCSI Session (Target side) |
|
| | | | |
|
| | (iSCSI Name + TSID=2) | | (iSCSI Name + TSID=1) |
|
| +----------------------------+ +-----------------------------+
|
|
|
| iSCSI Target Node
|
| (within Network Entity, not shown)
|
+-------------------------------------------------------------------+
(corrected?)
----------------------------IP Network---------------------
| | |
+----------|--------------|-----------------------|---------------------+
| | | |
|
| +----|----+ +----|----+ +----|----+
|
| | Network | | Network | | Network |
|
| | Portal | | Portal | | Portal |
|
| +---------+ +---------+ +---------+
|
| | | |
|
|
+--------|--------------|-----------------------|-------------------+ |
| | +----|--------------|------+ +------|-------+
| |
| | | Portal | | Portal |
| |
| | | Group 1 | | Group 2 |
| |
| | +--------------------------+ +--------------+
| |
| | | |
| |
| | +----------------------------+ +-----------------------------+
| |
| | | iSCSI Session (Target side)| | iSCSI Session (Target side) |
| |
| | | | | |
| |
| | | (iSCSI Name + TSID=2) | | (iSCSI Name + TSID=1) |
| |
| | +----------------------------+ +-----------------------------+
| |
| |
| |
| | iSCSI Target Node
| |
|
+-------------------------------------------------------------------+ |
|
|
| Network Entity
|
+-----------------------------------------------------------------------+
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
Jim Hafner
To:
11/01/2001 cc:
03:39 PM From:
Subject: (Document link: Andre Asselin)
Andre,
Your picture isn't quite right. The portal group tag is relative to the
iSCSI target and that target is *uniquely* identified by it's name. So, in
your picture, there are two targets (not one). Each can label its target
portal group any way it wants (independent of the other). Each has
independent control over the TSIDs it uses. Each may *share* use of a
network portal, but that's a different issue. The model implies two
independent targets (even if they live in the same network entity and share
resources) in your scenario.
In other words, the portal groups are wrt targets not the network entity.
In your scenario, whatever layer (you put it in the network code) has to
decide what session to add the connection to has the initiator name, the
ISID, the TSID *and* the target name (you left this out) in the login
request. That fully qualifies both the target and the session as well.
Jim Hafner
Andre Asselin
11/01/2001 12:15 pm
To: Jim Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not? (Document link:
Database 'Jim Hafner', View '($Inbox)')
Jim,
I agree with what you say, except for the part that mapping
TSID=target portal group tag will work.
Let's assume the following architecture: I have a network entity with one
network portal (and thus one portal group). Inside this entity lives two
iSCSI targets.
Scenerio: An iSCSI initiator opens a connection to the network portal in
order to add a connection to an already existing session (the network
entity's networking code knows this because TSID in the initial login
request is 0). The networking code needs to determine what session the
initiator wants to add to, so it compares some items from the initial login
request to each of the established sessions until it finds a match. The
question is what items should it compare to identify a match?
Section 3.12.9 of the spec reads:
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
As you say, this is clearly target centric (because, for example, an
initiator could have 2 different sessions open to two different targets
that have the same TSID). But from a target point of view, what that text
means to me that the network entity's networking code should compare ISID +
InitiatorName + TSID to determine a match. That implies that TSID must be
unique per TargetName and per portal group ID. If TSID is just the target
portal group tag, then the comparison wouldn't work. For example, using
the architecture above where there is just one portal group, the target
could have two sessions open: session A (InitiatorName=foo, ISID=1,
TargetName=bar, TSID=0) and session B (InitiatorName=foo, ISID=1,
TargetName=foobar, TSID=0). If it receives a login request with
(InitiatorName=foo, ISID=1, TSID=0), which session is it for?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
Jim Hafner
To: Andre Asselin/Raleigh/IBM@IBMUS
10/31/2001 06:33 PM cc: ips@ece.cmu.edu
From: Jim Hafner/Almaden/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?(Document link: Andre Asselin)
Andre,
First, your comment "SSID + InitiatorName must be enough to uniquely
identify a session" is target-centric. It would be different from the
initiator's viewpoint. However, from the target's viewpoint, the target
name is implicit and from the initiator viewpoint, the initiator name is
implicit, so globally, the triple of the two names + SSID (made up of the
ISID and TSID) form the identifier of the session. Locally (between two
specific guys), the names are implicit so only the SSID is required. It's
all a matter of point of view!
As for the difference in identifiers, as I mentioned in the private note,
the session is an iSCSI construct and is identified by iSCSI things. The
nexus is a SCSI thing and is identified by SCSI constructs (based on how
we've mapped the iSCSI things to SCSI things).
However, you've brought to the fore again a related question: "what value
does the TSID provide to the protocol?"
I'm not going to answer that, but I will note that one target
implementation that (I think) works is that the TSID = target portal group
tag.
The other thing to ask is "what value is there in the nexus identifier?"
This is never really used in SCSI at all, so it's not a critical issue what
composes it. However, it is important (IMO) that the SCSI ports have names
and the logical derivative of that statement is that the nexus is
identified by the concatenation of the SCSI port names (hence the
definition we have).
Jim Hafner
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 03:00:53 pm
Sent by: owner-ips@ece.cmu.edu
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or not?
John,
WHOOPS! I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID". When I was reading through it, I saw
"TargetName", but read to myself "TSID". Apologies...
In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.
Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another. If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers? Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre
Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
04:42 PM From: John Hufferd/San
Jose/IBM@IBMUS
Subject: Re: is TargetName
always mandatory or not?(Document link: Andre Asselin)
Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.
Please point out to me in the Spec (8 or above), where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image". "
" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID). "
I have not found a place where Session ID is tied to the TSID.
Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
John & Julian,
How about this for the section 5 text:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.
John,
I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID. The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag. There is no mention of TargetName
contributing to the identificaiton of a session. In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John
Hufferd/San To: Julian
Satran/Haifa/IBM@IBMIL
Jose/IBM@IBMUS cc: ips@ece.cmu.edu
Sent by: Subject: Re: is TargetName
always mandatory or not?
owner-ips@ece.
cmu.edu
10/31/2001
04:20 AM
Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login. It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication. The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target. Seems like a waste.
My I think that TargetName should also be on all connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair. It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to. And it is possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The leading Login
request MAY also include the SessionType key=value pair in which case if
the SessionType is not "discovery" then the leading Login Request MUST
also include the key=value pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
To: "IPS Reflector (E-mail)" <ips@ece.cmu.edu>
cc:
Subject: is TargetName always mandatory or not?
In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.". However, in Appendix D, the description for TargetName
says it is Leading Only.
Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
Home Last updated: Mon Nov 05 16:17:36 2001 7562 messages in chronological order |