|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] James Kempf's review comments on FCIP SLP
See jak>> and dap: below for James Kempf's expert review comments and
Dave Peterson's initial responses/explanations.
There do not appear to be any technical changes required, although
some clarifying text may be in order. FYI/Thanks, --David
IPS Working Group David Peterson
INTERNET-DRAFT Cisco Systems
<draft-ietf-ips-fcip-slp-04.txt> September 2002
Expires: March 2003
Category: standards-track
Finding FCIP Entities Using SLPv2
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The FCIP protocol [FCIP] provides a method for the tunneling of Fibre
Channel frames over an IP network. This document defines the use of
Service Location Protocol, version 2 (SLPv2) [RFC2608], by FCIP
Entities to discover one another, and provides the appropriate
templates describing their services.
Peterson Standards Track [Page 1]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
1. Acknowledgements
This draft was produced by the FCIP discovery team, including Todd
Sperry (Adaptec), Larry Lamars (SanValley), Robert Snively (Brocade),
Ravi Natarajan (Lightsand), Anil Rijhsinghani (McData), and Venkat
Rangan (Rhapsody Networks). Thanks also to Mark Bakke (Cisco) for
initial help and consultation.
2. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
Here are some definitions that may aid readers that are unfamiliar
with either SLP, or FCIP. Some of these definitions have been
reproduced from [RFC2608] and "Finding an RSIP Server with SLP"
[RSIP].
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 capabilites.
Directory Agent (DA) A process which 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.
FCIP Entity The principle FCIP interface point to the
IP network.
Peterson Standards Track [Page 2]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
FCIP Entity Name The world wide name of the switch if the
FCIP Entity resides in a switch or the
world wide node name of the associated
Nx_Port.
FCIP Discovery Domain The FCIP Discovery Domain specifies which
FCIP Entities are allowed to discover each
other within the bounds of the scope.
4. Using SLPv2 for FCIP Service Discovery
At least two FCIP Entities must be involved in the entity discovery
process. The end result is that an FCIP Entity will discover one or
more peer FCIP Entities.
4.1. Discovering FCIP Entities using SLPv2
The following diagram shows the relationship between FCIP Entities
and their associated SLPv2 agents.
+--------------------------------------+
| FCIP Entity |
+----------------------------------+ |
| FCIP Control and Services Module | |
+----------------+ | |
| SA | UA | | |
+----------------+-----------------+ |
| TCP/UDP/IP | |
+----------------+-----------------+ |
| Interface | |
| 180.10.1.10 | |
+----------------+-----------------+---|
|
+------------+ |
| SLPv2 DA |----+ IP Network
+------------+ |
|
+----------------+-----------------+---|
| Interface | |
| 190.10.1.20 | |
+----------------+-----------------+ |
| TCP/UDP/IP | |
+----------------+-----------------+ |
| SA | UA | | |
+----------------+ | |
| FCIP Control and Services Module | |
Peterson Standards Track [Page 3]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
+--------------------------------- + |
| FCIP Entity |
+--------------------------------------+
Fig. 1 FCIP Entity and SLPv2 Agent Relationship.
As indicated in the drawing above, each FCIP Entity contains an FCIP
Control and Services Module that interfaces to an SLPv2 SA and UA.
jak>> It sounds like the FCIP entities are peers, that is, there is no
client/server relationship. If that is not so, then there is no
need for an SA and UA in each entity.
dap: The FCIP entities are peers. No change.
jak>> DA should be indicted to be optional.
dap: a DA is already listed as optional in the SLPv2 spec. No change.
The SA constructs a service advertisement of the type
"service:fcip:entity" for each of the service URLs it wishes to
register. The service advertisement contains a lifetime, along with
other attributes defined in the service template.
jak>> Why use an abstract type? Is there any other concrete type
envisioned besides "entity"? If not, then a simple type should be used.
dap: Although no other concrete type was envisioned at the time,
consensus was to use the astract:concrete construct. No change.
The remainder of the discovery process is identical to that used by
any client/server pair implementing SLPv2:
1. If an SLPv2 DA is found [RFC2608], the SA contacts the DA and
registers the service advertisement. If SLPv2 DA is not found, the
SA maintains the service advertisement itself, and answers multicast
UA queries directly.
2. When the FCIP Entity requires contact information for a peer FCIP
Entity, the UA either contacts the DA using unicast or the SA using
multicast using an SLPv2 service request. The UA service request
includes a query, based on the attributes, to indicate the
characteristics of the peer FCIP Entities it requires.
3. Once the UA has the IP address and port number of a peer FCIP
Entity, it may begin the normal connection procedure, as described in
[FCIP], to a peer FCIP Entity.
The use of a DA is RECOMMENDED for SLPv2 operation in an FCIP
environment.
4.1.1. FCIP Discovery Domains
The concept of a discovery domain provides further granularity of
control of allowed discovery between FCIP Entities within a specific
SLPv2 scope.
The following example diagram shows the relationship between FCIP
Entities and their associated discovery domains within a specified
SLPv2 scope.
Peterson Standards Track [Page 4]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
=================fcip======================================================
=
=
= *************************purple**************************************
=
= * *
=
= * #####orange################################ *
=
= * # ----------------- /////////////////////+//blue////////////// *
=
= * # | FCIP Entity A | / # / *
=
= * # ----------------- / # ----------------- / *
=
= * # / # | FCIP Entity C | / *
=
= * # / ----------------- # ----------------- / *
=
= * # / | FCIP Entity B | # / *
=
= * # / ----------------- # / *
=
= * #####################+##################### / *
=
= * ////////////////////////////////////////// *
=
= * *
=
= *********************************************************************
=
=
=
===========================================================================
Fig. 2 FCIP Entity and Discovery Domain Example.
Within the specified scope "fcip", the administrator has defined a
discovery domain "purple", allowing FCIP Entities A, B, and C to
discover each other. This discovery domain is illustrated using the
"*" character.
Within the specified scope "fcip", the administrator has defined a
discovery domain "orange", allowing FCIP Entity A to discover FCIP
Entity B, but not FCIP Entity C. This discovery domain is
illustrated using the "#" character.
Within the specified scope "fcip", the administrator has defined a
discovery domain "blue", allowing FCIP Entity C to discover FCIP
Entity B, but not FCIP Entity A. This discovery domain is
illustrated using the "/" character.
4.2. NAT and NAPT Considerations
Since SLPv2 provides IP address and TCP port information within its
payload, the addresses an SA or DA advertise may not be the same as
those a UA must use if a Network Address(/Port) Translation
(NAT/NAPT) device is present between the UA and the SA. This may
result in the UA discovering address information that is unusable.
Below are a few recommendations to handle this:
Peterson Standards Track [Page 5]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
- A fully-qualified domain name (i.e., not an IP address) should be
used in service URLs and mgmt-entity attribute.
jak>> Is there any reason why an FQDN should not always be used?
dap: No reason to exclude the use of an IP address (e.g., if a NAT is
known to be not in the picture). No change.
- Use the default IANA-assigned FCIP TCP port number in service URLs,
when possible.
jak>> If the default port number is used by the service, it need not be
advertised.
dap: understood, this is implied and discussed in the SLPv2 spec.
No change.
- If advertising service URLs through a NAT/NAPT device, and the
FQDN, IP address, or TCP port will be translated, the NAT/NAPT
device can provide an SLPv2 proxy capability to do the translation.
jak>> Is this intended to apply to IPv4 only?
dap: not neccessarily, but certainly applies to the IPv4 realm. No change.
5. FCIP SLPv2 Templates
Two templates are provided: an FCIP Entity template, and an abstract
template to provide a means to add other FCIP related templates in
the future.
5.1. The FCIP Abstract Service Type Template
This template defines the abstract service "service:fcip". It is used
as a top-level service to encapsulate all other FCIP related
services.
Name of submitter: David Peterson
Language of service template: en
Security Considerations:
See the security considerations of the concrete service type.
Template Text:
-------------------------template begins here-----------------------
template-type=fcip
template-version=0.1
template-description=
This is an abstract service type. The purpose of the fcip service type
is to encompass all of the services used to support the FCIP protocol.
template-url-syntax =
url-path= ; Depends on the concrete service type.
--------------------------template ends here------------------------
Peterson Standards Track [Page 6]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
5.2. The FCIP Entity Concrete Service Type Template
This template defines the service "service:fcip:entity". A device
containing FCIP Entities that wishes to have them discovered via
SLPv2 would register each of them, with each of their addresses, as
this service type.
FCIP Entities wishing to discover other FCIP Entities in this manner
will generally use one of the following example query strings:
1. Find a specific FCIP Entity, given its FCIP Entity Name:
Service: service:fcip:entity
Scope: fcip-entity-scope-list
Query: (fcip-entity-name=10:00:00:60:69:20:34:0C)
2. Find all of the FCIP Entities within a specified FCIP Discovery
Domain:
Service: service:fcip:entity
Scope: fcip-entity-scope-list
Query: (fcip-discovery-domain=fcip-discovery-domain-name)
3. In addition, a management application may wish to discover all
FCIP Entities:
Service: service:fcip:entity
Scope: management-service-scope-list
Query: none
Name of submitter: David Peterson
Language of service template: en
Security Considerations:
See later section.
Template Text:
-------------------------template begins here-----------------------
template-type=fcip:entity
template-version=0.1
template-description=
This is a concrete service type. The fcip:entity service type is used
to register individual FCIP Entity addresses to be discovered by
others.
UAs will generally search for these by including one of the following:
- the FCIP Entity Name for which an address is needed
- the FCIP Discovery Domain Name for which addresses are requested
Peterson Standards Track [Page 7]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
- the service URL
template-url-syntax =
url-path = ipaddr [ : tcpport ] / fcip-entity-name
ipaddr = DNS host name or ip address
tcpport = decimal tcp port number
fcip-entity-name = FCIP Entity Name
; The fcip-entity-name portion of the URL is required and must be the
; FCIP Entity Name of the entity being registered.
; An entity representing multiple endpoints must register each of them
; using SLPv2.
;
; Examples:
; service:fcip:entity://hammer.cisco.com:4000/10:00:00:60:69:20:34:0C
; service:fcip:entity://192.1.3.40:4000/10:00:00:60:69:20:34:0C
;
; A DNS host name should be used along with the well-known IANA FCIP
; port number for allow for operation with NAT/NAPT devices.
jak>> I wouldn't include the IP address example at all, if an FQDN should
be used.
dap: an IP address is allowed. No change.
fcip-entity-name = opaque
# This must match the fcip-entity-name specified in the url-path.
# If the FCIP Entity is a VE_Port/B_Access implementation [FC-BB-2]
# residing in a switch, the fcip-entity-name is the Fibre Channel
# Switch Name [FC-SW-2]. Otherwise, the fcip-entity-name is the
# Fibre Channel Node Name [FC-FS] of the port (e.g., an Nx_Port)
# associated with the FCIP Entity.
jak>> Is there no reason why a text-based name should not be used? If
the name is in the URL, then a text based name should work.
dap: There is no guaranteed/reliable text-based name in the FC realm. As
such,
a switch name or node name is the unique identifier used as the entity name.
No change.
transports = string M L
tcp
# This is a list of transport protocols that the registered entity
# supports. FCIP is currently supported over TCP only.
tcp
mgmt-entity = string M O
# The URL's of the management interface(s) appropriate for SNMP,
# web-based, or telnet management of the FCIP Entity.
# Examples:
# snmp://10.1.1.1
# http://fcipentity.dap.com:1080/
# telnet://fcipentity.dap.com
fcip-discovery-domain = string M
fcip
# The fcip-discovery-domain string contains the name(s) of the FCIP
# discovery domain(s) to which this FCIP Entity belongs.
jak>> From the discussion in Section 4.1.1, I thought that the FCIP
domain was being equated to the SLP scope. Is there some reason for
making this a separate item?
dap: discovery domain is not equal to an SLP scope. Discovery domain(s)
reside within a scope and provide further granularity of control.
No change.
--------------------------template ends here------------------------
Peterson Standards Track [Page 8]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
6. Security Considerations
Service type templates provide information that is used to interpret
information obtained by clients through SLPv2. If the FCIP templates
are modified or if false templates are distributed, FCIP Entities may
not correctly register themselves or may not be able to interpret
service information.
The SLPv2 security model does not provide confidentiality, but does
provide an authentication mechanism for UAs to assure that service
advertisements only come from trusted SAs [RFC2608].
Once an FCIP Entity is discovered, authentication and authorization
are handled by the FCIP protocol. It is the responsibility of the
providers of these services to ensure that an inappropriately
advertised or discovered service, does not comprimise their security.
6.1. Security Implementation
For all implementations, IPsec SHOULD be implemented. When security
policy information distribution using SLPv2 is supported, IPsec MUST
be implemented.
To provide confidentiality, IPsec with ESP and a non-null transform
SHOULD be implemented. When security policy information distribution
via SLPv2 is used, IPsec with ESP and a non-null transform MUST be
used.
SLPv2 authentication is OPTIONAL to implement and use, and SLPv2
authentication SHOULD be implemented when IPsec is not supported.
The use of IPsec and IKE for SLPv2 in an IP storage environment is
described in [IPS-SEC].
jak>> I believe there are plans to issue an update of the SLPv2 draft with
a description of how to use IPsec with SLP, but, for now, this reference
is better because the update might take a while to complete. The planned
update is based on IPS-SEC. Might want to keep it in mind if a revision
is planned in the future.
dap: No change.
7. Summary
This document describes how SLPv2 can be used by FCIP Entities to
find other FCIP Entities. Service type templates for FCIP Entities
are presented.
8. Normative References
The references in this section were current at the time this
specification was approved. This specification is intended to operate
with newer versions of the referenced documents. Looking for newer
Peterson Standards Track [Page 9]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
references is recommended.
[RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service
Location Protocol, version 2", RFC 2608, July 1999.
[RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[FCIP] Rajagopal, et. al. "FCIP", draft-ietf-ips-
fcovertcpip-12.txt, June 2002.
[RSIP] Kempf, J., Montenegro, G. "Finding an RSIP Server with SLP",
draft-ietf-nat-rsip-slp-00, February 2000.
[FC-SW-2] Fibre Channel Switch Fabric - 2, ANSI INCITS.355:200x, May
23, 2001.
[FC-BB-2] Fibre Channel Backbone - 2, T11 Project 1238-D, Rev 5.6,
July 10, 2002.
[FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D, Rev
1.70, February 8, 2002.
[IPS-SEC] B. Aboba, et. al. "Securing Block Storage Protocols over
IP", draft-ietf-ips-security-16.txt, September 17, 2002.
9. Informative References
The references in this section may further assist the reader.
[RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and
service: Schemes", RFC 2609, July 1999.
[RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC
2614, June 1999.
[2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft-
kempf-srvloc-rfc2614bis-00.txt, February 2001.
[RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for
SLP", RFC 3082, March 2001.
[FCIP-MIB] Rijhsinghani, et. al. "FCIP MIB", draft-ietf-ips-fcip-
mib-01.txt, January 2002.
Peterson Standards Track [Page 10]
Internet-Draft Finding FCIP Entities Using SLPv2 September 2002
Author's Address:
David Peterson
Cisco Systems, Inc.
6450 Wedgwood Road
Maple Grove, MN
USA 55311
Voice: +1 763-398-1007
E-Mail: dap@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson Standards Track [Page 11]
Home Last updated: Fri Dec 06 12:19:04 2002 12056 messages in chronological order |