Network Working Group M. Bakke
Request for Comments: 4018 Cisco
Category: Standards Track J. Hufferd
K. Voruganti
IBM
M. Krueger
HP
T. Sperry
Adaptec
April 2005
Finding Internet Small Computer Systems Interface (iSCSI) Targets
and Name Servers by Using Service Location Protocol version 2 (SLPv2)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The iSCSI protocol provides a way for hosts to access SCSI devices
over an IP network. This document defines the use of the Service
Location Protocol (SLP) by iSCSI hosts, devices, and management
services, along with the SLP service type templates that describe the
services they provide.
Table of Contents
1. Introduction................................................ 2
2. Notation Conventions........................................ 2
3. Terminology................................................. 3
4. Using SLP for iSCSI Service Discovery....................... 4
5. iSCSI SLP Templates......................................... 11
6. Security Considerations..................................... 18
7. IANA Considerations......................................... 19
8. Summary..................................................... 19
9. Normative References........................................ 19
10. Informative References...................................... 20
11. Acknowledgements............................................ 21
1. Introduction
iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands,
data, and status across an IP network. This protocol is connection-
oriented and is currently defined over TCP. iSCSI uses a client-
server relationship. The client end of the connection is an
initiator, and it sends SCSI commands; the server end of the
connection is called a target, and it receives and executes the
commands.
There are several methods an iSCSI initiator can use to find the
targets to which it should connect. Two of these methods can be
accomplished without the use of SLP:
- Each target and its address can be statically configured on the
initiator.
- Each address providing targets can be configured on the initiator;
iSCSI provides a mechanism by which the initiator can query the
address for a list of targets.
The above methods are further defined in "iSCSI Naming and Discovery
Requirements" [RFC3721].
Each of the above methods requires a small amount of configuration to
be done on each initiator. The ability to discover targets and name
services without having to configure initiators is a desirable
feature. The Service Location Protocol (SLP) [RFC2608] is an IETF
standards track protocol providing several features that will
simplify locating iSCSI services. This document describes how SLP
can be used in iSCSI environments to discover targets, addresses
providing targets, and storage management servers.
2. Notation Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in [RFC2119].
3. Terminology
Here are some definitions that may aid readers who are unfamiliar
with SLP, SCSI, or iSCSI. Some of these definitions have been
reproduced from [RFC2608] and "Finding an RSIP Server with SLP"
[RFC3105].
User Agent (UA) A process working on the client's behalf
to establish contact with some service.
The UA retrieves service information from
the Service Agents or Directory Agents.
Service Agent (SA) A process working on behalf of one or more
services to advertise the services and
their capabilities.
Directory Agent (DA) A process that collects service
advertisements. There can only be one DA
present per given host.
Scope A named set of services, typically making
up a logical administrative group.
Service Advertisement A URL, attributes, and a lifetime
(indicating how long the advertisement is
valid) providing service access
information and capabilities description
for a particular service.
Initiator A logical entity, typically within a host,
that sends SCSI commands to targets to be
executed. An initiator is usually present
in the form of a device driver.
Target A logical entity, typically within a
storage controller or gateway that
receives SCSI commands from an initiator
and executes them. A target includes one
or more Logical Units (LUs); each LU is a
SCSI device, such as a disk or tape drive.
iSCSI Name A UTF-8 character string that serves as a
unique identifier for iSCSI initiators and
targets. Its format and usage is further
defined in [RFC3721].
iSCSI Client A logical entity, typically a host that
includes at least one iSCSI Initiator.
iSCSI Server A logical entity, typically a storage
controller or gateway that includes at
least one iSCSI Target.
Storage Management Server An addressable entity that provides
management services that benefit an iSCSI
environment. "Storage management server"
is used as a generic term and does not
indicate a specific protocol or service.
4. Using SLP for iSCSI Service Discovery
Two entities are involved in iSCSI discovery. The end result is that
an iSCSI initiator (e.g., a host) discovers iSCSI targets, usually
provided by storage controllers or gateways.
iSCSI targets are registered with SLP as a set of service URLs, one
for each address on which the target may be accessed. Initiators
discover these targets by using SLP service requests. Targets that
do not directly support SLP or that are under the control of a
management service may be registered by a proxy service agent as part
of the software providing this service.
iSCSI entities may also use SLP to discover higher-level management
services when these are needed.
This section first describes the use of SLP for discovery of targets
by iSCSI initiators, it then describes the use of SLP to discover
storage management servers.
This document assumes that SLPv2 will be used for discovering iSCSI-
related services; no attempt is made to include support for SLPv1.
4.1. Discovering iSCSI Targets with SLP
The following diagram shows the relationship among iSCSI clients,
servers, initiators, and targets. An iSCSI client includes at least
one iSCSI initiator, and an SLP user agent (UA). An iSCSI server
includes at least one iSCSI target an SLP service agent (SA). Some
entities, such as extended copy engines, include both initiators and
targets. These include both an SA, for its targets to be discovered,
and a UA, for its initiator(s) to discover other targets.
+---------------------------------+
| iSCSI Client |
| +-----------+ |
| | iSCSI | |
| | initiator | |
| | "myhost" | |
| +-----------+ |
| |
+--------------------------+------+
| iSCSI Driver | UA |
+--------------------------+------+
| TCP/UDP/IP |
+----------------+----------------+
| Interface 1 | Interface 2 |
+----------------+----------------+
| |
+------------+ | | +------------+
| SLP DA | | | | SLP DA |
| (optional) |----+ IP Networks +----| (optional) |
+------------+ | | +------------+
| |
+-----------------+-----------------|
| Interface 1 | Interface 2 |
| 192.0.2.131 | 192.0.2.3 |
+-----------------+-----------------+
| TCP/UDP/IP |
+---------------------------+-------+
| iSCSI Driver | SA |
+---------------------------+-------|
| |
| +--------+ +--------+ +---------+ |
| | iSCSI | | iSCSI | | iSCSI | |
| | target | | target | | target | |
| | "one" | | "two" | | "three" | |
| +--------+ +--------+ +---------+ |
| iSCSI Server |
+-----------------------------------+
In the above drawing, the iSCSI server has three iSCSI targets that
the client could discover, named "one", "two" and "three". The iSCSI
client has an iSCSI initiator with the name "myhost". The iSCSI
client may use the initiator name in its SLP Service Requests as a
filter to discover only targets that are configured to accept iSCSI
connections from "myhost".
Each iSCSI target and initiator has a unique name, called an iSCSI
Name. This identifier is the same regardless of the network path
(through adapter cards, networks, and interfaces on the storage
device) over which the target is discovered and accessed. For this
example, the iSCSI names "one", "two", and "three" are used for the
targets; the initiator uses the name "myhost". An actual iSCSI name
would incorporate more structure, including a naming authority, and
is not described here.
Each of the iSCSI targets in the drawing can appear at two addresses,
since two network interfaces are present. Each target would have two
service URLs, unless a single service URL included a DNS host name
mapping to both addresses.
An iSCSI target URL consists of its fully qualified host name or IP
address, the TCP port on which it is listening, and its iSCSI name.
An iSCSI server must register each of its individual targets at each
of its network addresses.
The iSCSI server constructs a service advertisement of the type
"service:iscsi:target" for each of the service URLs it wishes to
register. The advertisement contains a lifetime, along with other
attributes that are defined in the service template.
If the server in the above drawing is listening at TCP port 3260 for
both network addresses, the service URLs registered would be
- 192.0.2.131:3260/one
- 192.0.2.131:3260/two
- 192.0.2.131:3260/three
- 192.0.2.3:3260/one
- 192.0.2.3:3260/two
- 192.0.2.3:3260/three
The remainder of the discovery procedure is identical to that used by
any client/server pair implementing SLP:
1. If an SLP DA is found, the SA contacts the DA and registers the
service advertisement. Whether or not one or more SLPv2 DAs are
discovered, the SA maintains the advertisement itself and answers
multicast UA queries directly.
2. When the iSCSI initiator requires contact information for an
iSCSI target, the UA either contacts the DA by using unicast or
the SA by using multicast. If a UA is configured with the
address of the SA, it may avoid multicast and may contact an SA
by using unicast. The UA includes a query based on the
attributes to indicate the characteristics of the target(s) it
requires.
3. Once the UA has the host name or address of the iSCSI server, as
well as the port number and iSCSI Target Name, it can begin the
normal iSCSI login to the target.
As information contained in the iSCSI target template may exceed
common network datagram sizes, the SLP implementation for both UAs
and SAs supporting this template MUST implement SLP over TCP.
4.1.1. Finding Targets Based on Initiator Credentials
To be allowed access to an iSCSI target, an initiator must be
authenticated. The initiator may be required by the target to
produce one or more of the following credentials:
- An iSCSI Initiator Name
- An IP address
- A CHAP, SRP, or Kerberos credential
- Any combination of the above
Most iSCSI targets allow access to only one or two initiators. In
the ideal discovery scenario, an initiator would send an SLP request
and receive responses ONLY for targets to which the initiator is
guaranteed a successful login. To achieve this goal, the iSCSI
target template contains the following attributes, each of which
allows a list of values:
1. auth-name: This attribute contains the list of initiator names
allowed to access this target, or the value "any", indicating
that no specific initiator name is required.
2. auth-addr: This attribute contains the list of host names
and/or IP addresses that will be allowed access to this target,
or the value "any", indicating that no specific address or
host name is required. If a large number of addresses is to
be allowed (perhaps a subnet), this attribute may contain the
value "any".
3. auth-cred: This attribute contains a list of "method/identifier"
credentials that will be allowed access to the target, provided
they can produce the correct password or other verifier during
the login process. If no specific credentials are required, the
value "any" is used.
The list of valid method strings for auth-cred are defined in
[RFC3720], section 11.1, "AuthMethod". The identifier used after the
"/" is defined by the specific AuthMethod, also in [RFC3720].
Examples showing initiator searches based on auth-xxxx attributes are
shown in the target-specific template section below.
Also note that the auth-xxxx attributes are considered security
policy information. If these attributes are distributed, IPsec MUST
be implemented as specified in the Security Implementation section
below.
4.1.2. Supporting Access by Multiple Identities to the Same Target
If a target is to allow access to multiple host identities, more than
one combination of auth-xxxx attributes will have to be allowed. In
some of these cases, it is not possible to express the entire set of
valid combinations of auth-xxxx attributes within a single registered
service URL. For example, if a target can be addressed by
auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)
OR
auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)
the above cannot be specified in a single registered service URL,
since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1,
auth-cred=CHAP/user2) would allow either auth-name to be used with
either auth-cred. This necessitates the ability to register a target
and address under more than one service URL; one for (identity1) and
one for (identity2).
Because service URLs must be unique, (identity1) and (identity2) must
each be registered under a unique service URL. For systems that
support the configuration of multiple identities to access a target,
the service URL must contain an additional, opaque string defining
the identity. This appears after the iSCSI name in the URL string
and is separated by a "/". Each registered (target-address, target-
name, initiator-identity) tuple can then register a set of auth-xxxx
attributes.
4.1.3. Using SLP in a Non-multicast Environment
In some networks, the use of multicast for discovery purposes is
either unavailable or not allowed. These include public or service-
provider networks that are placed between an iSCSI client and a
server. These are probably most common between two iSCSI gateways,
one at a storage service provider site, and one at a customer site.
In these networks, an initiator may allow the addresses of one or
more SAs to be configured instead of or in addition to its DA
configuration. The initiator would then make unicast SLP service
requests directly to these SAs, without the use of multicast to
discover them first.
This functionality is well within the scope of the current SLP
protocol. The main consequence for implementors is that an initiator
configured to make direct unicast requests to an SA will have to add
this to the SLP API, if it is following the service location API
defined in [RFC2614].
4.2. Discovering Storage Management Services with SLP
Storage management servers can be built to manage and control access
to targets in a variety of ways. They can provide extended services
beyond discovery, which could include storage allocation and
management. None of these services are defined here; the intent of
this document is to allow these services to be discovered by both
clients and servers, in addition to the target discovery already
being performed.
The following drawing shows an iSCSI client, an iSCSI server, and a
storage management server. To simplify the drawing, the second IP
network is not shown but is assumed to exist. The storage management
server would use its own protocol (smsp) to provide capabilities to
iSCSI clients and servers; these clients and servers can both use SLP
to discover the storage management server.
+---------------------------+
| iSCSI Client |
| |
| +-----------+ |
| | iSCSI | |
| | initiator | |
| +-----------+ |
| |
+---------------+------+----+ +------------+
| iSCSI Driver | smsp | UA | | SLP DA |
+---------------+------+----+ | |
| TCP/UDP/IP | | (optional) |
+---------------+------+----+ +------------+
| |
| IP Network |
------------------------------------------
| |
| |
+---------------+-----------+ +---------------------+
| TCP/UDP/IP | | TCP/UDP/IP |
+---------------+------+----+ +---------------------+
| iSCSI Driver | smsp | UA | | SA | smsp |
+---------------+------+----+ +---------------------+
| | | |
| +--------+ +--------+ | | storage mgmt server |
| | iSCSI | | iSCSI | | | |
| | target | | target | | +---------------------+
| | 1 | | 2 | |
| +--------+ +--------+ |
| |
| iSCSI Server |
+---------------------------+
Note the difference between the storage management server model and
the previously defined target discovery model. When target discovery
was used, the iSCSI Server implemented an SA, to be discovered by the
initiator's UA. In the storage management server model, the iSCSI
clients and servers both implement UAs, and the management server
implements the SA.
A storage management server's URL contains the domain name or IP
address and TCP or UDP port number. No other information is
required.
The storage management server constructs a service advertisement of
the type "service:iscsi:sms" for each of the addresses at which it
appears. The advertisement contains the URL and a lifetime, along
with other attributes that are defined in the service template.
The remainder of the discovery procedure is identical to that used to
discover iSCSI targets, except that both initiators and targets would
normally be "clients" of the storage management service.
Targets that support a storage management service implement a UA in
addition to the SA. A target may alternatively just implement the UA
and allow the storage management service to advertise its targets
appropriately by providing an SA and registering the appropriate
service:iscsi:target registrations on the target's behalf: The target
device would not have to advertise its own targets. This has no
impact on the initiator.
This allows the initiators' discovery of targets to be completely
interoperable regardless of which storage management service is used,
or whether one is used at all, or whether the target registrations
are provided directly by the target or by the management service.
4.3. Internationalization Considerations
SLP allows internationalized strings to be registered and retrieved.
Attributes in the template that are not marked with an 'L' (literal)
will be registered in a localized manner. An "en" (English)
localization MUST be registered, and others MAY be registered.
Attributes that include non-ASCII characters will be encoded by using
UTF-8, as discussed in [RFC3722] and [RFC3491].
5. iSCSI SLP Templates
Three templates are provided: an iSCSI target template, a management
service template, and an abstract template to encapsulate the two.
5.1. The iSCSI Abstract Service Type Template
This template defines the abstract service "service:iscsi". It is
used as a top-level service to encapsulate all other iSCSI-related
services.
Name of submitter: Mark Bakke
Language of service template: en
Security Considerations: See section 6.
Template Text:
-------------------------template begins here-----------------------
template-type=iscsi
template-version=1.0
template-description=
This is an abstract service type. The purpose of the iscsi
service type is to encompass all of the services used to support
the iSCSI protocol.
template-url-syntax=
url-path= ; Depends on the concrete service type.
--------------------------template ends here------------------------
5.2. The iSCSI Target Concrete Service Type Template
This template defines the service "service:iscsi:target". An entity
containing iSCSI targets that wishes them discovered via SLP would
register each of them, with each of their addresses, as this service
type.
Initiators (and perhaps management services) wishing to discover
targets in this way will generally use one of the following queries:
1. Find a specific target, given its iSCSI Target Name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (iscsi-name=iqn.2001-04.com.example:sn.456)
2. Find all of the iSCSI Target Names that may allow access to a
given initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (auth-name=iqn.1998-03.com.example:hostid.045A7B)
3. Find all of the iSCSI Target Names that may allow access to
any initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (auth-name=any)
4. Find all of the iSCSI Target Names that may allow access to
this initiator, or that will allow access to any initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: &(auth-name=iqn.1998-03.com.example:hostid.045A7B)
(auth-name=any)
5. Find all of the iSCSI Target Names that may allow access to
a given CHAP user name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (auth-cred=chap/my-user-name)
6. Find all of the iSCSI Target Names that may allow access to a
given initiator that supports two IP addresses, a CHAP credential
and SRP credential, and an initiator name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any)
|(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any)
|(auth-cred=chap/foo)(auth-cred=srp/my-user-name)
(auth-cred=any))
7. Find the iSCSI Target Names from which the given initiator is
allowed to boot:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B)
8. In addition, a management service may wish to discover all
targets:
Service: service:iscsi:target
Scope: management-server-scope-list
Query:
文章来源于领测软件测试网 https://www.ltesting.net/
版权所有(C) 2003－2010 TestAge（领测软件测试网）|领测国际科技（北京）有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系：info@testage.com.cn 电话：010-51297073