Difference between revisions of "RFC3822"
imported>Admin (Created page with " Network Working Group D. Peterson Request for Comments: 3822 Computer Network Technology (CNT) Category: Standards Tra...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Network Working Group D. Peterson | Network Working Group D. Peterson | ||
Request for Comments: 3822 Computer Network Technology (CNT) | Request for Comments: 3822 Computer Network Technology (CNT) | ||
Category: Standards Track July 2004 | Category: Standards Track July 2004 | ||
− | |||
Finding Fibre Channel over TCP/IP (FCIP) Entities | Finding Fibre Channel over TCP/IP (FCIP) Entities | ||
Using Service Location Protocol version 2 (SLPv2) | Using Service Location Protocol version 2 (SLPv2) | ||
− | Status of this Memo | + | '''Status of this Memo''' |
This document specifies an Internet standards track protocol for the | This document specifies an Internet standards track protocol for the | ||
Internet community, and requests discussion and suggestions for | Internet community, and requests discussion and suggestions for | ||
improvements. Please refer to the current edition of the "Internet | improvements. Please refer to the current edition of the "Internet | ||
− | Official Protocol Standards" (STD 1) for the standardization state | + | Official Protocol Standards" ([[STD1|STD 1]]) for the standardization state |
and status of this protocol. Distribution of this memo is unlimited. | and status of this protocol. Distribution of this memo is unlimited. | ||
− | Copyright Notice | + | '''Copyright Notice''' |
Copyright (C) The Internet Society (2004). | Copyright (C) The Internet Society (2004). | ||
− | Abstract | + | '''Abstract''' |
This document defines the use of Service Location Protocol version 2 | This document defines the use of Service Location Protocol version 2 | ||
Line 41: | Line 34: | ||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
− | document are to be interpreted as described in [RFC2119]. | + | document are to be interpreted as described in [[RFC2119]]. |
== Terminology == | == Terminology == | ||
Line 47: | Line 40: | ||
Here are some definitions that may aid readers that are unfamiliar | Here are some definitions that may aid readers that are unfamiliar | ||
with either SLP or FCIP. Some of these definitions have been | with either SLP or FCIP. Some of these definitions have been | ||
− | reproduced from [RFC2608] and [RFC3105]. | + | reproduced from [[RFC2608]] and [[RFC3105]]. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
User Agent (UA) A process working on the client's behalf | User Agent (UA) A process working on the client's behalf | ||
Line 102: | Line 86: | ||
Figure 1 shows the relationship between FCIP Entities and their | Figure 1 shows the relationship between FCIP Entities and their | ||
associated SLPv2 agents. | associated SLPv2 agents. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+--------------------------------------+ | +--------------------------------------+ | ||
Line 154: | Line 130: | ||
any client/server pair implementing SLPv2: | any client/server pair implementing SLPv2: | ||
− | 1. If an SLPv2 DA is found [RFC2608], the SA contacts the DA and | + | 1. If an SLPv2 DA is found [[RFC2608]], the SA contacts the DA and |
registers the service advertisement. Whether or not one or more | registers the service advertisement. Whether or not one or more | ||
SLPv2 DAs are discovered, the SA maintains the service | SLPv2 DAs are discovered, the SA maintains the service | ||
advertisement itself and answers multicast UA queries directly. | advertisement itself and answers multicast UA queries directly. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
2. When the FCIP Entity requires contact information for a peer FCIP | 2. When the FCIP Entity requires contact information for a peer FCIP | ||
Line 172: | Line 143: | ||
3. Once the UA has the IP address and port number of a peer FCIP | 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 | Entity, it may begin the normal connection procedure, as described | ||
− | in [RFC3821], to a peer FCIP Entity. | + | in [[RFC3821]], to a peer FCIP Entity. |
The use of a DA is RECOMMENDED for SLPv2 operations in an FCIP | The use of a DA is RECOMMENDED for SLPv2 operations in an FCIP | ||
Line 209: | Line 180: | ||
Figure 2: FCIP Entity and Discovery Domain Example. | Figure 2: FCIP Entity and Discovery Domain Example. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Within the specified scope "fcip", the administrator has defined a | Within the specified scope "fcip", the administrator has defined a | ||
Line 265: | Line 229: | ||
template-description= | template-description= | ||
This is an abstract service type. The purpose of the fcip service | 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 | type is to encompass all of the services used to support the FCIP | ||
Line 318: | Line 278: | ||
template-version=0.1 | template-version=0.1 | ||
− | |||
− | |||
− | |||
− | |||
template-description= | template-description= | ||
Line 367: | Line 323: | ||
# supports. FCIP is currently supported over TCP only. | # supports. FCIP is currently supported over TCP only. | ||
tcp | tcp | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
mgmt-entity = string M O L | mgmt-entity = string M O L | ||
Line 392: | Line 340: | ||
== Security Considerations == | == Security Considerations == | ||
− | The SLPv2 security model as specified in [RFC2608] does not provide | + | The SLPv2 security model as specified in [[RFC2608]] does not provide |
confidentiality, but does provide an authentication mechanism for UAs | confidentiality, but does provide an authentication mechanism for UAs | ||
to assure that service advertisements only come from trusted SAs with | to assure that service advertisements only come from trusted SAs with | ||
the exception that it does not provide a mechanism for authenticating | the exception that it does not provide a mechanism for authenticating | ||
− | "zero-result responses". See [RFC3723] for a discussion of the SLPv2 | + | "zero-result responses". See [[RFC3723]] for a discussion of the SLPv2 |
− | [RFC2608] security model. | + | [[RFC2608]] security model. |
Once an FCIP Entity is discovered, authentication and authorization | Once an FCIP Entity is discovered, authentication and authorization | ||
Line 424: | Line 372: | ||
These three measures (i.e., IP address range limits, DNS domain | These three measures (i.e., IP address range limits, DNS domain | ||
limits, negative authentication cache) MUST be implemented. | limits, negative authentication cache) MUST be implemented. | ||
− | |||
− | |||
− | |||
− | |||
=== Security Implementation === | === Security Implementation === | ||
Security for SLPv2 in an IP storage environment is specified in | Security for SLPv2 in an IP storage environment is specified in | ||
− | [RFC3723]. IPsec is mandatory-to-implement for IPS clients and | + | [[RFC3723]]. IPsec is mandatory-to-implement for IPS clients and |
servers. Thus, all IP storage clients, including those invoking SLP, | servers. Thus, all IP storage clients, including those invoking SLP, | ||
can be assumed to support IPsec. SLP servers, however, cannot be | can be assumed to support IPsec. SLP servers, however, cannot be | ||
Line 439: | Line 383: | ||
running on machines other than those running the IPS protocols. | running on machines other than those running the IPS protocols. | ||
− | IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this | + | IPsec SHOULD be implemented for SLPv2 as specified in [[RFC3723]]; this |
includes ESP with a non-null transform to provide both authentication | includes ESP with a non-null transform to provide both authentication | ||
and confidentiality. | and confidentiality. | ||
Line 445: | Line 389: | ||
Because the IP storage services have their own authentication | Because the IP storage services have their own authentication | ||
capabilities when located, SLPv2 authentication is OPTIONAL to | capabilities when located, SLPv2 authentication is OPTIONAL to | ||
− | implement and use (as discussed in more detail in [RFC3723]). | + | implement and use (as discussed in more detail in [[RFC3723]]). |
== IANA Considerations == | == IANA Considerations == | ||
Line 451: | Line 395: | ||
This document describes two SLP Templates in Section 5. They should | This document describes two SLP Templates in Section 5. They should | ||
be registered in the IANA "SVRLOC Templates" registry. This process | be registered in the IANA "SVRLOC Templates" registry. This process | ||
− | is described in the IANA Considerations section of [RFC2609]. | + | is described in the IANA Considerations section of [[RFC2609]]. |
== Internationalization Considerations == | == Internationalization Considerations == | ||
Line 466: | Line 410: | ||
are presented. | are presented. | ||
− | + | 10. Acknowledgements | |
This document was produced by the FCIP discovery team, including Todd | This document was produced by the FCIP discovery team, including Todd | ||
Line 475: | Line 419: | ||
James Kempf for assistance during expert review. | James Kempf for assistance during expert review. | ||
+ | 11. References | ||
+ | 11.1. Normative References | ||
+ | [[RFC2608]] Guttman, E., Perkins, C., Veizades, J. and M. Day, | ||
+ | "Service Location Protocol, Version 2", [[RFC2608|RFC 2608]], June | ||
+ | 1999. | ||
+ | [[RFC2609]] Guttman, E., Perkins, C. and J. Kempf, "Service Templates | ||
+ | and Service: Schemes", [[RFC2609|RFC 2609]], June 1999. | ||
+ | [[RFC2119]] Bradner, S., "Key Words for Use in RFCs to Indicate | ||
+ | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. | ||
+ | [[RFC3821]] Rajagopal, M., Bhagwat, R. and R. Weber, "Fibre Channel | ||
+ | Over TCP/IP (FCIP)", [[RFC3821|RFC 3821]], July 2004. | ||
+ | |||
+ | [FC-SW-3] Fibre Channel Switch Fabric - 3, ANSI INCITS 384-2004. | ||
+ | |||
+ | [FC-BB-2] Fibre Channel Backbone - 2, ANSI INCITS 372-2003. | ||
+ | [FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D, | ||
+ | Rev 1.90, April 9, 2003. | ||
− | + | [[RFC3723]] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. | |
+ | Travostino, "Securing Block Storage Protocols over IP", | ||
+ | [[RFC3723|RFC 3723]], April 2004. | ||
− | + | 11.2. Informative References | |
− | + | [[RFC3105]] Kempf, J. and G. Montenegro, "Finding an RSIP Server with | |
− | + | SLP", [[RFC3105|RFC 3105]], October 2001. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 12. Author's Address | |
− | |||
David Peterson | David Peterson | ||
Line 507: | Line 462: | ||
EMail: [email protected] | EMail: [email protected] | ||
− | + | 13. Full Copyright Statement | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2004). This document is subject | ||
Line 559: | Line 504: | ||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | ||
Internet Society. | Internet Society. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:Standards Track]] | [[Category:Standards Track]] |
Latest revision as of 09:33, 4 October 2020
Network Working Group D. Peterson Request for Comments: 3822 Computer Network Technology (CNT) Category: Standards Track July 2004
Finding Fibre Channel over TCP/IP (FCIP) Entities 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 (2004).
Abstract
This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities.
Contents
- 1 Introduction
- 2 Notation Conventions
- 3 Terminology
- 4 Using SLPv2 for FCIP Service Discovery
- 5
- 6 *************************purple***********************
- 7 * *
- 8 * #####orange###################### *
- 9 * # ------------ //////blue//////+/////////////// *
- 10 * # | FCIP | / # / *
- 11 * # | Entity A | / # / *
- 12 * # ------------ / # ------------ / *
- 13 * # / # | FCIP | / *
- 14 * # / # | Entity C | / *
- 15 * # / ------------ # ------------ / *
- 16 * # / | FCIP | # / *
- 17 * # / | Entity B | # / *
- 18 * # / ------------ # / *
- 19 * ################+################ / *
- 20 * //////////////////////////////// *
- 21 * *
- 22 ******************************************************
- 23
Introduction
This document describes the use of the Service Location Protocol version 2 in performing dynamic discovery of participating Fibre Channel over TCP/IP (FCIP) Entities. Implementation guidelines, service type templates, and security considerations are specified.
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.
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 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 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.
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.
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.
Discovering FCIP Entities using SLPv2
Figure 1 shows the relationship between FCIP Entities and their associated SLPv2 agents.
+--------------------------------------+ | FCIP Entity | +----------------------------------+ | | FCIP Control and Services Module | | +----------------+ | | | SA | UA | | | +----------------+-----------------+ | | TCP/UDP/IP | | +----------------+-----------------+ | | Interface | | | 192.0.2.10 | | +----------------+-----------------+---| |
+------------+ | | SLPv2 DA |----+ IP Network +------------+ |
| +----------------+-----------------+---| | Interface | | | 192.0.2.20 | | +----------------+-----------------+ | | TCP/UDP/IP | | +----------------+-----------------+ | | SA | UA | | | +----------------+ | | | FCIP Control and Services Module | | +--------------------------------- + | | FCIP Entity | +--------------------------------------+
Figure 1: FCIP Entity and SLPv2 Agent Relationship.
As indicated in Figure 1, each FCIP Entity contains an FCIP Control and Services Module that interfaces to an SLPv2 SA and UA.
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.
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. Whether or not one or more SLPv2 DAs are discovered, 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 RFC3821, to a peer FCIP Entity.
The use of a DA is RECOMMENDED for SLPv2 operations in an FCIP environment.
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.
Figure 2 shows an example relationship between FCIP Entities and their associated discovery domains within a specified SLPv2 scope.
===========fcip=================================
*************************purple***********************
* *
* #####orange###################### *
* # ------------ //////blue//////+/////////////// *
* # | FCIP | / # / *
* # | Entity A | / # / *
* # ------------ / # ------------ / *
* # / # | FCIP | / *
* # / # | Entity C | / *
* # / ------------ # ------------ / *
* # / | FCIP | # / *
* # / | Entity B | # / *
* # / ------------ # / *
* ################+################ / *
* //////////////////////////////// *
* *
******************************************************
================================================
Figure 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.
For the example relationship shown in Figure 2, the value of the fcip-discovery-domain attribute for each FCIP Entity is as follows:
FCIP Entity A = orange,purple
FCIP Entity B = orange,blue,purple
FCIP Entity C = blue,purple
FCIP SLPv2 Templates
Two templates are provided: an FCIP Entity template, and an abstract template to provide a means of adding other FCIP related templates in the future.
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 section 6.
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------------------------
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=\ff\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 section 6.
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 - the service URL
template-url-syntax =
url-path = hostport hostport = host [ ":" port ] host = hostname / hostnumber hostname = *( domainlabel "." ) toplabel alphanum = ALPHA / DIGIT domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum toplabel = ALPHA / ALPHA * [ alphanum / "-" ] alphanum hostnumber = ipv4-number ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) port = 1*DIGIT
; ; A DNS host name should be used along with the well-known ; IANA FCIP port number for operation with NAT/NAPT devices. ; ; Examples: ; service:fcip:entity://host.example.com ; service:fcip:entity://192.0.2.0:4000 ;
fcip-entity-name = opaque L
- 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-3]. 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.
- An entity representing multiple endpoints must register each of
- the endpoints using SLPv2.
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 L
- The URL's of the management interface(s) are appropriate for SNMP,
- web-based, or telnet management of the FCIP Entity.
- Examples:
- http://fcipentity.example.com:1080/
- telnet://fcipentity.example.com
fcip-discovery-domain = string M L fcip
- The fcip-discovery-domain string contains the name(s) of the FCIP
- discovery domain(s) to which this FCIP Entity belongs.
template ends here------------------------
Security Considerations
The SLPv2 security model as specified in RFC2608 does not provide confidentiality, but does provide an authentication mechanism for UAs to assure that service advertisements only come from trusted SAs with the exception that it does not provide a mechanism for authenticating "zero-result responses". See RFC3723 for a discussion of the SLPv2 RFC2608 security model.
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 compromise their security.
When no security is used for SLPv2, there is a risk of distribution of false discovery information. The primary countermeasure for this risk is authentication. When this risk is a significant concern, IPsec SAs SHOULD be used for FCIP traffic subject to this risk to ensure that FCIP traffic only flows between endpoints that have participated in IKE authentication. For example, if an attacker distributes discovery information falsely claiming that it is an FCIP endpoint, it will lack the secret information necessary to successfully complete IKE authentication, and hence will be prevented from falsely sending or receiving FCIP traffic.
There remains a risk of a denial of service attack based on repeated use of false discovery information that will cause the initiation of IKE negotiation. The countermeasures for this are administrative configuration of each FCIP Entity to limit the peers that it is willing to communicate with (i.e., by IP address range and/or DNS domain), and maintenance of a negative authentication cache to avoid repeatedly contacting an FCIP Entity that fails to authenticate. These three measures (i.e., IP address range limits, DNS domain limits, negative authentication cache) MUST be implemented.
Security Implementation
Security for SLPv2 in an IP storage environment is specified in RFC3723. IPsec is mandatory-to-implement for IPS clients and servers. Thus, all IP storage clients, including those invoking SLP, can be assumed to support IPsec. SLP servers, however, cannot be assumed to implement IPsec, since there is no such requirement in standard SLP. In particular, SLP Directory Agents (DA) may be running on machines other than those running the IPS protocols.
IPsec SHOULD be implemented for SLPv2 as specified in RFC3723; this includes ESP with a non-null transform to provide both authentication and confidentiality.
Because the IP storage services have their own authentication capabilities when located, SLPv2 authentication is OPTIONAL to implement and use (as discussed in more detail in RFC3723).
IANA Considerations
This document describes two SLP Templates in Section 5. They should be registered in the IANA "SVRLOC Templates" registry. This process is described in the IANA Considerations section of RFC2609.
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.
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.
10. Acknowledgements
This document 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, and David Black, Erik Guttman, and James Kempf for assistance during expert review.
11. References
11.1. Normative References
RFC2608 Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June 1999.
RFC2609 Guttman, E., Perkins, C. and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999.
RFC2119 Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC3821 Rajagopal, M., Bhagwat, R. and R. Weber, "Fibre Channel
Over TCP/IP (FCIP)", RFC 3821, July 2004.
[FC-SW-3] Fibre Channel Switch Fabric - 3, ANSI INCITS 384-2004.
[FC-BB-2] Fibre Channel Backbone - 2, ANSI INCITS 372-2003.
[FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D,
Rev 1.90, April 9, 2003.
RFC3723 Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
11.2. Informative References
RFC3105 Kempf, J. and G. Montenegro, "Finding an RSIP Server with
SLP", RFC 3105, October 2001.
12. Author's Address
David Peterson Computer Network Technology (CNT) 6000 Nathan Lane North Minneapolis, MN 55442
Phone: 763-268-6139 EMail: [email protected]
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- [email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.