idnits 2.17.1 draft-ietf-ips-framework-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 40) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 805 has weird spacing: '...routing pro...' == Line 873 has weird spacing: '...is will be a...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2000) is 8561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2026' on line 27 looks like a reference -- Missing reference section? 'RFC2119' on line 113 looks like a reference -- Missing reference section? 'SCSI-3' on line 128 looks like a reference -- Missing reference section? 'FCP' on line 132 looks like a reference -- Missing reference section? 'CAM' on line 134 looks like a reference -- Missing reference section? 'FCoverIP' on line 182 looks like a reference -- Missing reference section? 'T11' on line 916 looks like a reference -- Missing reference section? 'FCBB' on line 835 looks like a reference -- Missing reference section? '3' on line 724 looks like a reference -- Missing reference section? 'FC-FS' on line 1301 looks like a reference -- Missing reference section? 'RFC2418' on line 1674 looks like a reference -- Missing reference section? 'RFC1157' on line 1688 looks like a reference -- Missing reference section? 'RFC2578' on line 1692 looks like a reference -- Missing reference section? 'RFC2837' on line 1703 looks like a reference -- Missing reference section? 'RFC2625' on line 1705 looks like a reference -- Missing reference section? 'FCMIB' on line 1709 looks like a reference -- Missing reference section? 'FIMIB' on line 1712 looks like a reference -- Missing reference section? 'RFC2143' on line 1714 looks like a reference -- Missing reference section? 'RFC760' on line 1726 looks like a reference -- Missing reference section? 'RFC761' on line 1726 looks like a reference -- Missing reference section? 'RFC1180' on line 1728 looks like a reference -- Missing reference section? 'RFC813' on line 1728 looks like a reference -- Missing reference section? 'RFC879' on line 1730 looks like a reference -- Missing reference section? 'RFC869' on line 1733 looks like a reference -- Missing reference section? 'RFC955' on line 1735 looks like a reference -- Missing reference section? 'RFC962' on line 1735 looks like a reference -- Missing reference section? 'RFC2001' on line 1808 looks like a reference -- Missing reference section? 'RFC2101' on line 1740 looks like a reference -- Missing reference section? 'RFC2330' on line 1740 looks like a reference -- Missing reference section? 'RFC2415' on line 1741 looks like a reference -- Missing reference section? 'RFC2414' on line 1742 looks like a reference -- Missing reference section? 'RFC2581' on line 1808 looks like a reference -- Missing reference section? 'RFC2151' on line 1744 looks like a reference -- Missing reference section? 'RFC2140' on line 1746 looks like a reference -- Missing reference section? 'X500' on line 1763 looks like a reference -- Missing reference section? 'RFC2251' on line 1763 looks like a reference -- Missing reference section? 'RFC2830' on line 1774 looks like a reference -- Missing reference section? 'RFC2256' on line 1775 looks like a reference -- Missing reference section? 'RFC2255' on line 1776 looks like a reference -- Missing reference section? 'RFC2254' on line 1777 looks like a reference -- Missing reference section? 'RFC2252' on line 1778 looks like a reference -- Missing reference section? 'RFC2247' on line 1778 looks like a reference -- Missing reference section? 'RFC1591' on line 1788 looks like a reference -- Missing reference section? 'RFC2914' on line 1809 looks like a reference -- Missing reference section? 'RFC2979' on line 1818 looks like a reference -- Missing reference section? 'RFC1631' on line 1827 looks like a reference -- Missing reference section? 'RFC2663' on line 1828 looks like a reference -- Missing reference section? 'RFC1918' on line 1829 looks like a reference -- Missing reference section? 'RFC2050' on line 1830 looks like a reference -- Missing reference section? 'RFC2766' on line 1830 looks like a reference -- Missing reference section? 'RFC2504' on line 1855 looks like a reference -- Missing reference section? 'RFC2411' on line 1859 looks like a reference -- Missing reference section? 'RFC2828' on line 1860 looks like a reference -- Missing reference section? 'RFC2709' on line 1866 looks like a reference -- Missing reference section? 'RFC2401' on line 1870 looks like a reference -- Missing reference section? 'RFC1511' on line 1872 looks like a reference -- Missing reference section? 'RFC2402' on line 1876 looks like a reference -- Missing reference section? 'RFC2406' on line 1879 looks like a reference -- Missing reference section? 'RFC1630' on line 1895 looks like a reference -- Missing reference section? 'RFC1738' on line 1921 looks like a reference -- Missing reference section? 'RFC2624' on line 1918 looks like a reference -- Missing reference section? 'NFS4' on line 1919 looks like a reference -- Missing reference section? 'RFC2224' on line 1919 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 65 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Storage 2 Internet Draft 3 Document: November 17, 2000 4 Category: Informational 6 Mark A. Carlson 7 Sun Microsystems, Inc. 9 Satish Mali 10 StoneFly Networks 12 Milan Merhar 13 Pirus Networks 15 Charles Monia 16 Nishan Systems 18 Murali Rajagopal 19 LightSand Communications 21 A Framework for IP Based Storage 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026 [RFC2026]. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. Internet-Drafts are draft documents valid for a maximum of 32 six months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- Drafts 34 as reference material or to cite them other than as "work in 35 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents 43 1. Abstract 44 2. Conventions 45 3. Overview 46 4. Scope 47 5. Applicable Protocols 48 6. Environments 49 6.1 Naming and discovery 50 6.2 The Internet Storage Environment 51 6.3 iSCSI Environment 52 6.4 FC over IP Environment 53 6.5 iFCP, mFCP and iSNS 54 7. Fibre Channel Network Overview 55 7.1 The Fibre Channel Network 56 7.1.1 Multi-Switch Fibre Channel Fabric 57 7.2 Fibre Channel Layers and Link Services 58 7.2.1 Fabric-Supplied Link Services 59 7.3 Fibre Channel Devices 60 7.4 Fibre Channel Information Elements 61 7.4.1 Fibre Channel Frame Format 62 7.5 Fibre Channel Transport Services 63 7.6 N_PORT to N_PORT Communication 64 8. Definitions 65 9. Security Considerations 66 10. References 67 11. Acknowledgements 68 12. Authors Addresses 69 Appendix A: Existing Internet Standards and Procedures 70 A.1 IETF and RFC overview 72 A.2 RFC summary 73 A.3 Management of TCP/IP based devices 74 A.4 Fibre Channel related standards 75 A.5 Standards related to TCP and IP 76 A.6 Standards related to Naming and Discovery topics 77 A.6.1 LDAP 78 A.6.2 DNS 79 A.6.3 iSCSI Name Server 80 A.7 Flow Control related Standards 81 A.8 Standards related to Firewall, NAT 82 A.9 Security and Authentication related Standards 83 A.10 Addressing and other Miscellaneous Standards 84 A.11 Network File related protocols 86 1. Abstract 88 This document serves as a framework for the creation of standards in 89 the IP based storage working group of the IETF. The environment 90 surrounding IP based storage is explained and an overview of the 91 applicable standards and protocols is provided. References to 92 current and expected IP based storage standards in this area are 93 provided. This document provides a background for participants who 94 are experienced in either the storage industry or the networking 95 industry but needs to understand the applicable standards and 96 conventions used in the other respective industry. 98 2. Conventions used in this document 100 The acronym _SCSI_ is typically used to describe both a parallel- 101 wire bus interconnection used for storage attachment and the 102 command/response protocol first developed for use over that 103 interconnect. 105 Within this document, _SCSI_ will be used generically to refer to 106 the protocol, independent of transport, while specific reference to 107 its parallel bus transport will use the term _parallel SCSI._ 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC-2119 112 [RFC2119]. 114 3. Overview 116 As computer systems grow in size and complexity, their non-volatile 117 storage capacity is often expanded through the addition of external 118 media, such as magnetic and optical disks and magnetic tape. 119 Various interconnection methods have been developed to support this 120 storage expansion, with the Small Computer Systems Interface, or 121 parallel SCSI, being one of the most commonly used. 123 As originally conceived, SCSI defined both the parallel-wire bus 124 interconnection between a computer system and its storage devices, 125 and the command/response protocol used to transfer information over 126 that interconnection. Over time, both aspects of the specification 127 have been refined and extended, supporting higher speed transport 128 technologies, and a more complex command syntax [SCSI-3]. 129 The SCSI protocol has also been used over transport other than 130 parallel SCSI, such as high speed serial Fibre Channel. This 131 combination, commonly called a Fibre Channel Storage Area Network or 132 Fibre Channel SAN [FCP], permits more flexible connectivity than 133 allowed by parallel SCSI, while maintaining the common SCSI 134 controller API [CAM] used by the computer system to access its 135 storage devices. 137 These specialized transports provide substantial benefit in the 138 local storage environment, but require dedicated fiber connections 139 to extend to larger geographic distances. This has driven efforts 140 to reconcile SAN technology with ubiquitous IP transport, to provide 141 a _best of both worlds_ environment. 143 4. Scope 145 The IP Storage Working Group is developing several different but 146 complimentary solutions for SAN extension. They all share the goal 147 of maintaining existing computer system and storage device APIs, 148 although they each define different demarcation points where 149 existing practice interfaces with new technology. Some of these 150 proposed solutions are individual submissions and are not official 151 working group work items. This document serves as a survey of these 152 proposed techniques. 154 Briefly, all of these solutions allow SCSI operations to be 155 performed transparently between an operating system driver and a 156 target device controller, while making different trade-offs as to 157 how much of the Fibre Channel SAN environment will be preserved 158 unchanged, and how much will be translated into IP networking 159 equivalents. 161 One set of proposed solutions maintains the switched Fibre Channel 162 SAN environment, but introduces IP as a supported fabric or link 163 technology. Due to the mixed nature of the resulting network, 164 components of two different network architectures (Fibre Channel SAN 165 and Internet) may need to be supported in the operational 166 environment. 168 It should be noted that SCSI is only one of a number of higher-layer 169 protocols having mappings to Fibre Channel, so solutions of this 170 type have the potential of supporting applications beyond SCSI 171 storage access. 173 FCIP provides a standard way of encapsulating FC frames within 174 TCP/IP, allowing islands of FC SANs to be interconnected over an IP- 175 based network. TCP/IP is used as the underlying transport to provide 176 congestion control and in-order delivery of error-free data. All 177 classes of FC frames are treated the same -- as datagrams. End- 178 station addressing, address resolution, message routing, and other 179 fundamental elements of the network architecture remain unchanged 180 from the Fibre Channel model, with IP introduced exclusively as a 181 transport protocol for an inter-network bridging function. 182 [FCoverIP]. 184 iFCP is a gateway-to-gateway protocol for the implementation of a 185 fibre channel fabric over a TCP/IP transport. Using iFCP, all 186 traffic between fibre channel devices is routed and switched by 187 TCP/IP network components instead of fibre channel components. Its 188 goal is to bring IP technology to the considerable installed base of 189 fibre channel storage products [iFCP]. This is an individual 190 submission and is not currently a work item of the working group. 192 The mFCP protocol is a variant of iFCP that provides Fibre Channel 193 fabric services to FCP-based Fibre Channel devices using a high- 194 performance, reliable IP network. mFCP uses the UDP transport 195 protocol to facilitate high performance, and assumes that 196 reliability and flow control will be handled by the physical 197 infrastructure. mFCP's primary objective is to allow 198 interconnection and networking of existing Fibre Channel devices 199 over an IP network [mFCP]. This is an individual submission and is 200 not currently a work item of the working group. 202 A somewhat different solution maintains the SCSI protocol interface 203 unchanged, with IP introduced as another transport beneath it, much 204 as Fibre Channel was introduced as an alternative transport to 205 parallel SCSI. In this model, end-station addressing, address 206 resolution, message routing etc. all follow the Internet model. This 207 solution allows the existing IP support infrastructure to be 208 leveraged in maintaining the SAN environment, supporting all 209 operations that may be performed within the SCSI command syntax 210 [iSCSI]. 212 5. Applicable Protocols 214 It is recommended that implementers familiarize themselves with the 215 applicable protocols and standards that exist from the IETF and 216 Fibre Channel standards organizations. Appendix A is an overview of 217 some of these standards and the procedures that are used in the 218 IETF. 220 IP based storage standards will leverage these existing standards 221 for transport, management, discovery and naming. 223 6. Environments 225 6.1 Naming and discovery 227 Every storage-related entity could find information about other 228 storage resources in several ways. The Fibre Channel based storage 229 resources have a state transition where every node goes through the 230 process of login for the fabric. The process of login in Fibre 231 channel assigns a World Wide name to the device. This Worldwide Name 232 is unique in that domain and is used by other devices to uniquely 233 address this device. 235 It is required that the IP based storage shall support the naming 236 architecture of SAM-2. In order to fulfill the SAM-2 architecture 237 requirements, it is necessary to understand the naming and discovery 238 process used in Fibre Channel based networks and IP based networks. 240 The naming and discovery architectures for IP based storage 241 resources can be seen from two different views. One view is to 242 provide naming and discovery process conventions using current IP 243 based architecture. This may involve using various standards such as 244 DNS, LDAP, and URL. The other view is to extend the naming and 245 discovery process of the current Fibre Channel based architecture to 246 fit within the boundaries of IP. Here is a summary about the various 247 proposals and their issues. 249 Fibre Channel based Naming and Discovery: 251 The Fibre Channel based storage devices are connected in a meshed 252 topology to provide redundant paths from initiator to target device. 253 The initiator can identify these redundant paths by traversing 254 different paths to the target and discovering that the multiple 255 paths lead to the same target. In case one of the paths becomes 256 unavailable, the initiator conducts communication over the redundant 257 path. It may be also necessary to take into account changes proposed 258 by T10 committee that allows LUN renumbering. Refer to SPC-2 259 provisions for LU Identifiers (Vital product data page 83h [SPC-2, 260 p. 203]). 262 IP based naming and discovery: 264 In IP based network, connected devices are also uniquely identified 265 by their IP address and the DNS name. There maybe multiple paths 266 from one device to the other. However, the main difference is that 267 the routers along the path take care of managing a unique path from 268 one end to another end. In case one of the paths has a problem, the 269 alternate path is opened by the router, without end nodes being 270 involved and aware of the transition-taking place for the in-between 271 paths. 273 Here is one way of representing IP based storage resources. 275 URL based naming: 277 One of the iSCSI-naming schemes involves use of URL. The proposal 278 here is to use the popular World Wide Web based URL encoding scheme 279 to denote the storage entities within a target. 281 A URL for the target may have the following form: 283 scsi://hostname/path/with/ 285 A URL referring to a specific LU has the following form: 287 scsi://hostname/path/with/?LUN=lunnumber?WWN=wwnnumber 289 If no LUN= term appears in the URL, then LUN 0 is assumed. 291 The WWN= term is optional. If present, the party should verify 292 that the WWN in the LU's Device Identification Inquiry Page 293 corresponds to the WWN. 295 An example of the above scheme will be: 297 scsi://ips.ietf.org/tape/?WWN=0a050a4bcdefa 299 Refers to LUN 0 of target scsi://ips.ietf.org/tape/. After 300 connecting, the initiator verifies that the WWN of the LU is 301 0a050a4bcdefa. 303 Discovery: 305 Traditional SCSI discovery is based on a "bus walker" paradigm. Here 306 every logical combination is searched for availability of a valid 307 SCSI device. For a small number of devices connected to the parallel 308 SCSI bus, this approach was not too time consuming. But when SCSI 309 was implemented over Fibre Channel, the Fibre Channel introduced 310 notion of World Wide Name (WWN) as device identifier. The WWN, which 311 is made of 64 bits, could not iterate through every 64 bit WWN and 312 still boot quickly. The Solution to that problem involved using a 313 multi-round distributed address assignment scheme for Fibre Channel 314 Arbitrated Loop environment and to query the name server for all 315 known ports in Fibre Channel Switched environment. The Name Server 316 in the Fibre Channel Switch kept track of each connected WWN. 318 IP based storage systems goal is not to alter any discovery 319 mechanism in IP, as current mechanism based on DNS is quite evolved 320 and the current management solutions use the existing structure to 321 get IP address information, however, addition IP based mechanisms 322 for discovery and naming may be specified by the working group. It 323 is also required that there is a way to identify that the discovered 324 entity does indeed have an IP based storage device. The problem is 325 compounded by the existence of NAT and firewalls installed in the 326 working environments. NAT and firewalls can hide a private network 327 behind a public IP address, effectively shielding access to all the 328 IP based storage devices from outside. The external device then 329 cannot make an inquiry to the individual IP based storage device. 331 Here is a brief overview of the issues involved and likely reasons 332 behind each option. 334 If the SCSI over IP discovery mechanism is maintained to be same as 335 current DNS method, then there is no additional burden on 336 understanding and administrating IP based systems. It can then be 337 used in conjunction with current management solutions. The 338 discovered storage entity can be verified by querying on iSCSI well- 339 known port. This port is assigned to iSCSI by IANA and is used to 340 service iSCSI based requests. Absence of any response from this 341 well-known port will indicate absence of IP based SCSI device. 342 NAT/Firewall is still a problem and need a different type of 343 solution to reach to storage devices on the private side of the NAT. 344 This can be handled by using IPsec based tunneling protocols that 345 can set up a private tunnel to the private network, from where all 346 the devices are now accessible. However, this means that IPsec based 347 session may be required to be initiated during boot process to 348 access boot drive inside the NAT/firewall area. 350 One issue that may have to be addressed is the reliability of DNS 351 access. In mission critical environments it may not be enough to 352 solely depend on the availability of primary or secondary DNS 353 servers, and IP based access to volumes may be required. 355 Global context for third party names is an open issue in T10. In 356 general, the Initiator of a 3rd party command must use names that 357 resolve to the desired LUNs from the third party command Target's 358 naming perspective. It is required that both Initiator and Target 359 may have to share the same naming context. This needs to be handled 360 in the IP based storage devices similar to Fibre Channel based 361 storage. 363 The two networks meet: 365 The issues that need to be resolved for IP based storage are: 367 * Naming scheme that takes into account current target LU and LUN 368 based convention and maps it to IP based storage. 369 * Discovery process that can work with or without firewalls and NAT 370 units. 371 * Authentication scheme that allows connections and management of 372 the storage devices. 373 * Provide SCSI third party operations that allow hand over of naming 374 schemes. 375 * Provide a security scheme in SCSI, which defines proxy-naming 376 scheme that allows a given LU within a target to be addressed by 377 different LUNs. 378 * Scalability of the storage domain such as storage Service 379 Providers requiring large number of storage devices. 381 6.2 The Internet Storage Environment 383 Much of this section is based upon [iSCSI-REQ]. The material has 384 been expanded, where appropriate, to reflect all the storage-related 385 solutions being addressed by the IPS working group. 387 The use of IP technology for storage may be divided into three broad 388 categories: 390 * The direct attachment of volume/block-oriented storage devices to 391 an IP network, 392 * The implementation of IP Fabrics, for the interconnection of fibre 393 channel storage devices using IP routing and switching elements. 394 * Backbones for the interconnection of storage clusters of fibre 395 channel storage area networks across data centers. 397 For these applications, the IP/Ethernet infrastructure offers the 398 following compelling advantages: 400 * Increasing performance and reduced cost driven by Internet 401 economics and "IP convergence" 402 * Seamless conversion from local to wide area using IP routers 403 * Emerging availability of "IP datatone" service from carriers, in 404 preference to ATM or SONET or T-1, T-3 services 405 * Protocols and middleware for management, security and QoS 406 * Economies arising from the need to install and operate only a 407 single type of network 408 IP technology will be applied to the following storage applications: 410 * Storage area networks, providing local storage access, 411 consolidation, clustering and pooling (as in the data center), 412 * The integration of storage area networks across data centers, 413 * Remote disk access (as for a storage utility), 414 * Local and remote synchronous and asynchronous mirroring between 415 storage controllers, 416 * Local and remote backup and restore, 417 * Evolution with SCSI to support of emerging object-oriented storage 418 model. 420 And the following connection topologies are contemplated: 422 * Point-to-point direct connections, 423 * Dedicated storage LAN, consisting of one or more LAN segments, 424 * Shared LAN, carrying a mix of traditional LAN traffic plus storage 425 traffic, 426 * LAN-to-WAN extension using IP routers or carrier-provided "IP 427 Datatone", 428 * Private networks and the public Internet. 429 * Backbones, interconnecting clusters of fibre channel or IP-based 430 storage area networks. 432 Local-area storage networks will be built using Ethernet LAN 433 switches. These networks may be dedicated to storage, or shared 434 with traditional Ethernet uses, as determined by cost, performance, 435 administration, and security considerations. In the local area, 436 TCP's adaptive retransmission timers will provide for automatic and 437 rapid error detection and recovery, compared to alternative 438 technologies. 440 IP LAN-WAN routers will be used to extend the IP storage network to 441 the wide area, permitting remote disk access (as for a storage 442 utility), synchronous and asynchronous remote mirroring, and remote 443 backup and restore (as for tape vaulting). In the WAN, TCP end-to- 444 end will avoid the need for specialized equipment for protocol 445 conversion, ensure data reliability, cope with network congestion, 446 and automatically adapt retransmission strategies to WAN delays. 448 6.2.1 Internet Storage Migration Issues 450 This section discusses issues that arise as storage subsystems, 451 migrate to the Internet and are released from the implicit 452 constraints imposed by closed storage interconnects. These 453 constraints have related to: 455 Connectivity _- the achievable device population, 457 Openness _ The potential for sharing network resources with other 458 devices and applications, 459 Device address volatility _ The stability of the physical device 460 address over time. 462 Reach _ The physical span of the network and its effect on I/O 463 performance and behavior, 465 The storage subsystem model _ the process of defining and assembling 466 a collection of storage devices dispersed throughout the network 467 into a pool of resources available to an application. 469 The device's view of the storage network _ The assumptions a device 470 may make regarding how the storage network appears to other devices. 472 The paradigm for storage transactions _ The basic command-response 473 model for I/O operations, 475 Security _ The effects of extending the storage subsystem beyond the 476 physical confines of the chassis or computer room. These 477 considerations are discussed in section [???]. 479 6.3 iSCSI Environment 481 6.3.1 System models and addressing 483 The basic system model for iSCSI is that of an extended virtual 484 cable, connecting a SCSI initiator device to a SCSI target device. 486 +---------+ +--------+ 487 |Initiator| | Target | 488 SCSI | iSCSI | IP | iSCSI | SCSI 489 Initiator >| Device | Network| Device |> Target 490 | E-HBA |<------>| E-disk | 491 +---------+ +--------+ 493 Both iSCSI initiator and iSCSI target are identified completely by 494 their IP addresses, although some implementations may also assign a 495 dummy SCSI or FC address to an internal interface for purposes of 496 compatibility (e.g. _ to support an existing SCSI I/O driver.) _ 498 Unfortunately, reality has not yet caught up with the simplicity of 499 this model. In the near term, it appears there will be several 500 implementations of initiator iSCSI adapters (so-called _Ethernet 501 Host Bus Adapters_) but few disk drives with native Ethernet/IP 502 interfaces. 504 Instead, considerable effort has gone into the development of iSCSI 505 proxy devices, which provide a gateway from the IP Storage protocol 506 to an existing storage interconnection such as Fibre Channel or 507 parallel SCSI, which in turn attaches to conventional storage 508 devices. For example, a server using a native iSCSI HBA may be 509 attached to a conventional storage array via Fibre Channel in this 510 manner: 512 +---------+ +--------+ +--------+ 513 |Initiator| | Gateway| | | 514 SCSI | iSCSI | IP | iSCSI | |SCSI/FC | 515 Initiator >| Device | Network| Device | FC | Target | 516 | E-HBA |<------>| A |<----->| | 517 +---------+ +--------+ +--------+ 519 As with the previous model, the initiator iSCSI device and the IP 520 interface of gateway device A are identified by an IP address. 521 In this example, gateway device A also has a Fibre Channel interface 522 (i.e. _ either a N_Port or a NL port,) connected to a Fibre Channel 523 fabric or arbitrated loop as an initiator, allowing iSCSI commands 524 received from the IP network to be sent to the actual target device. 525 As the gateway device only presents a single address to the Fibre 526 Channel network, all iSCSI initiators using this gateway will appear 527 on the Fibre Channel as originating from a single address. 529 Similar iSCSI gateway devices have also been proposed as WAN 530 interconnections between existing Fibre Channel SANs. 532 +---------+ +--------+ +--------+ +--------+ 533 | | | Gateway| | Gateway| | | 534 | SCSI/FC | FC | iSCSI | IP WAN | iSCSI | FC |SCSI/FC | 535 |Initiator| SAN 1 | Device | Network| Device | SAN 2| Target | 536 | |<------->| B |<------>| C |<----->| | 537 +---------+ +--------+ +--------+ +--------+ 538 <--- SCSI ---> <--- IP ---> <--- SCSI ---> 539 <----------- Virtual SCSI Connection -------------> 541 In this configuration, gateway device B appears as a target device 542 on FC SAN 1, accepting attachments as a proxy for the actual SCSI 543 target residing on FC SAN 2. Similarly, gateway device C appears as 544 an initiator device on FC SAN 2, initiating attachments as a proxy 545 for the actual SCSI initiator on FC SAN 1. 547 SCSI operations occurring between the initiator and target are 548 actually performed in three stages; by a SCSI operation occurring 549 between initiator and Gateway B, by transfer of the request via 550 iSCSI between Gateway B and Gateway C, and by a separate SCSI 551 operation performed by Gateway C on the target device. In other 552 words, the initiator's SCSI requests are accepted locally, but the 553 responses are delayed by the response time of the remote proxy 554 operation, plus the WAN round-trip delay. 556 Note that independent local contexts (address space, Name server 557 contents, Zoning configuration, etc.) are maintained for both SAN 1 558 and SAN 2, unless they are explicitly synchronized through 559 configuration or other means outside the scope of this document. 561 This type of _remote access_ to SCSI devices across the WAN should 562 be contrasted with the SAN extension solutions provided by FC/IP or 563 iFCP/mFCP (as described in sections 6.4 and 6.5 below.) Those 564 solutions extend the context of a Fibre Channel SAN by transparently 565 bridging protocol messages from one SAN to the other, without 566 terminating and remotely recreating SCSI sessions. 568 6.3.2 Operation 570 iSCSI [iSCSI] is a connection-oriented command/response protocol. 571 An iSCSI session begins with an iSCSI initiator connecting to an 572 iSCSI target (typically, using TCP) and performing an iSCSI login. 573 This login creates a persistent state between initiator and target, 574 which may include initiator and target authentication, session 575 security certificates, and session option parameters. 577 Once this login has been successfully completed, the iSCSI session 578 continues in _full feature_ phase. The iSCSI initiator may issue 579 SCSI commands encapsulated by the iSCSI protocol over its TCP 580 connection, which are executed by the iSCSI target. The iSCSI target 581 must return a status response for each command over the same TCP 582 connection, consisting of both the completion status of the actual 583 SCSI target device and its own iSCSI session status. 585 An iSCSI session is terminated when its TCP session is closed. This 586 shutdown is graceful if all outstanding SCSI operations have been 587 permitted to complete; closing a session while SCSI operations are 588 outstanding may require implementation and target-specific cleanup 589 actions to be performed. 591 6.3.2.1 iSCSI data flow 593 The same TCP session used for command/status is also used to 594 transfer data and/or optional command parameters. 596 For SCSI commands that require data and/or parameter transfer, the 597 (optional) data and the status for a command must be sent over the 598 same TCP connection that was used to deliver the SCSI command. 600 Data transferred from the iSCSI initiator to iSCSI target can be 601 either unsolicited, or solicited. Unsolicited data may be sent 602 either as part of an iSCSI command message, or as separate data 603 messages (up to an agreed-upon limit negotiated between initiator 604 and target at login.) Solicited data is sent only in response to a 605 target-initiated Ready to Transfer message. 607 Each iSCSI command, Data, and Ready to Transfer message carries a 608 tag, which is used to associate a SCSI operation with its associated 609 data transfer messages. 611 6.3.3 Auxiliary services 612 6.3.3.1 Discovery services 614 Close examination of the _inter-SAN gateway_ model described in 615 section 6.3.1 above reveals several operations that rely on some 616 form of discovery service. 618 If gateway devices B and C are to communicate across the IP network, 619 one must know the IP address of the other. The definition of 620 services to detect and identify these resources is the subject of 621 ongoing work. 623 A different form of discovery occurs within the Fibre Channel 624 regions of a mixed IP storage network. Consider the right port of 625 gateway C, which for purposes of discussion is assumed to be 626 attached to a Fibre Channel switch. To access that switch, the 627 gateway must log into the fabric, identifying itself as an initiator 628 device. It may then query the Name server on SAN 2 for the addresses 629 of available target devices, and probe them to determine what 630 Logical Units they contain. 632 Similarly, the left port of gateway B logs into its attached Fibre 633 Channel switch, identifying itself as a target device, so that its 634 address can be added to the Name server on SAN 1. If probed by a 635 Fibre Channel initiator device, gateway B initiates an iSCSI session 636 with gateway C, allowing the SCSI requests to be satisfied by the 637 actual SCSI target device. 639 6.3.3.2 Relationship to NAT devices 641 As shown above, a single storage network may contain regions of IP, 642 Fibre Channel, and parallel SCSI connectivity, each using different 643 addressing schemes. Moreover, many networks of today's Internet are 644 reachable only through NAT, for reasons both technical and 645 administrative. 647 This fragmentation of addressing space imposes additional 648 constraints on any resource identification or location service; the 649 address of a resource may depend on who is asking, and what path a 650 connection to that resource would take. For example, a target 651 device might be identified by its Fibre Channel address to another 652 device on the same fabric, by the local (e.g. _ Net.10) IP address 653 of an iSCSI gateway to a local IP Storage initiator, and the public 654 IP address of a NAT device to an remote iSCSI initiator. 656 This same concern applies to information passed within the iSCSI 657 protocol itself; resource location strings and other meta-addressing 658 information must be interpretable correctly within the context of 659 the destination device. 661 Finally, address information presented through a network management 662 interface, such as SNMP, must include sufficient contextual 663 information to be unambiguous. In particular, it should be noted 664 that network management applications might aggregate data from 665 multiple devices into a consolidated report. 667 6.3.4 Configuration issues 669 6.3.4.1 Address management 671 From the IP perspective, addresses can be assigned to iSCSI devices 672 using conventional dynamic address assignment tools. 674 However, system-level concerns, such as allowing a server to boot 675 via its iSCSI interface without the support of external services, 676 may require static IP address assignment or other self-contained 677 solution to be used in some environments. 679 iSCSI devices acting as gateways may also participate in Fibre 680 Channel Arbitrated loops and switched fabric SANs as end-stations, 681 acting as an initiator and/or target device. As such, they will also 682 interact with existing SAN address management systems (e.g. _ the 683 Fibre Channel SAN name server.) 685 6.4 FC over IP (FCIP) Environment 687 6.4.1 FCIP Environment 689 FCIP is a protocol specification that allows a FCIP device to 690 transparently tunnel FC frames across an IP-based Network. This 691 capability is applicable in edge devices that interface with a FC 692 Switch [T11] or FC-BBW device [FCBB]. The term FCIP device generally 693 refers to an edge device that encapsulates FC frames into TCP 694 segments and re-assembles TCP segments to regenerate FC frames. 696 The motivation behind connecting remote sites using the FCIP device 697 is to enable transparent disk or tape backup and live mirroring, or 698 simply distance extension between two FC devices or FC Switch 699 clusters (SAN islands) across an IP-based network. The transparency 700 implies that the FCIP edge devices need not examine the FC frame 701 content or even preserve FC state information and effectively provide 702 a fast frame forwarding function just like FC switches. That is the 703 FCIP device is a transparent translation point. This also means that 704 the FC datagrams are expected to comply with existing FC 705 specifications as far as delay latency is concerned. The FC traffic 706 may span LANs, MANs and WANs, so long as this fundamental assumption 707 is adhered to. 709 The IP network is not aware of the FC payload that it is carrying. 710 Likewise, the FC fabric and the FC end nodes are unaware of the (TCP) 711 IP-based transport. 713 6.4.2 Fibre Channel Backbone Switches Background 714 Fibre Channel (FC) Standards [T11] describe the operation of and 715 interaction between FC Switches. Two distinct levels of switch 716 interconnections are specified. Autonomous Regions (AR) are 717 defined to allow clusters of FC Switches to be connected across a 718 backbone network called an FSPF-backbone. An Autonomous Region is 719 administratively defined with each AR encompassing one or more FC 720 Domains. The FSPF-backbone network is formed from one or more 721 Backbone Switches (BSW) that run the FSPF-backbone routing protocol. 722 The FSPF-backbone routing protocol is based on OSPF and the FSPF 723 backbone may consist of an arbitrary mesh network. A BSW may 724 communicate with multiple neighbors. As specified in [3], native FC 725 frames traverse the backbone between BSW neighbors. The FSPF-backbone 726 Routing Protocol messages are exchanged between BSWs on the FSPF 727 backbone. 729 An example network consisting of 4 ARs and an FSPF backbone 730 consisting of 3 links is given in Fig. 6.4.1. There is no restriction 731 in adding other links to this network as needed. The connection 732 between BSWs below may in fact form a fully connected mesh. 734 _______ _______ 735 | | | | 736 | AR #1 |_____ _____| AR #4 | 737 |_______| | | |_______| 738 ___|___ ___|___ 739 | BSW 1 |---------------------| BSW 4 | 740 |_______| |_______| 741 ___|___ _______ 742 | BSW 2 |---------------------| BSW 3 | 743 |_______| |_______| 744 ___ ___ | | _______ 745 | | | | | | 746 | AR #2 |----- -----| AR #3 | 747 |_______| |_______| 749 Fig. 6.4.1 Example Network showing FSPF-Backbone Switching 750 Architecture 752 Note: 753 BSW 1 knows it is connected to BSWs 2 and 4; 754 BSW 2 knows it is connected to BSWs 1 and 3; 755 BSW 4 knows it is connected to BSWs 1. 757 An FCIP device provides a single, logical interface to the FSPF- 758 backbone protocol connecting multiple BSW neighbors on the IP- 759 network. From the FSPF-backbone routing's point of view, the 760 connection to each neighbor on the IP-network is treated as a 761 separate logical FC link. 763 In FCIP, the native FC frames are first encapsulated in TCP segments, 764 which then traverse the IP-based network. The IP network provides a 765 new transport path for each emulated FSPF-backbone link. 767 The IP network itself may consist of any number of hops between two 768 FCIP devices. Also, the route taken by the IP packet between any two 769 FCIP devices is dictated by normal IP routing. 771 A functional and logical diagram of an IP-based FSPF-backbone for the 772 example network given in Fig. 6.4.3 is shown in Fig. 6.4.2. In this 773 figure, each BSW is logically connected to other BSWs. 775 The IP-based network has transformed the FSPF-backbone into a fully 776 connected network. From the perspective of each BSW all remote BSWs 777 therefore appear to be neighbors. The FSPF-backbone routing protocol 778 computations would make the IP-based network topology appear as a 779 fully connected mesh. 781 _______ _______ 782 | | | | 783 | AR #1 |--- | AR #4 | 784 |_______| | ______ ________ ______ |_______| 785 __|_ __ | | | | | | ___|___ 786 | BSW 1 |---| FCIP |--| IP |--| FCIP |--| BSW 4 | 787 |_______| |______| | Network| |______| |_______| 788 | | 789 -------- 790 ______ | | ______ 791 ______ | | | | | | _______ 792 | BSW 2|---| FCIP |-----| |---| FCIP |---| BSW 3 | 793 |______| |______| |______| |_______| 794 ________ | ___|___ 795 | | | | | 796 | AR #2 |__| | AR #3 | 797 |________| |_______| 799 Fig. 6.4.2 Example Network showing an IP-based FC Backbone Switching 800 Architecture 802 The FSPF-backbone routing protocol exchanges specified in [T11] 803 between BSWs occur transparently to the FCIP devices. Encapsulated 804 FC frames are routed on the IP network according to the normal IP 805 routing procedures. In this mode, the FSPF backbone routing 806 protocol lies over the IP network and has no knowledge of the 807 underlying IP protocol and IP routing or the underlying technology 808 that carries the IP datagram. This concept is shown in Fig.6.4.3 810 ________ _______ 811 | AR #1 | | AR #2 | 812 | |-- | | 813 |________| | ______ ________ _____ |_______| 814 __|___ | | | | | | ____|__ 815 | BSW 1|---| FCIP |--| IP |--|FCIP |--| BSW 2 | 816 | | | | | Network| | | | | 817 |______| |______| |________| |_____| |_______| 818 <--------------> 819 IP Routing 820 <----------------------------------> 821 FSPF-backbone Routing Plane 823 Fig. 6.4.3 FC packet routing over IP based backbone network 825 Note: IP Network routing may consist of multiple paths 827 6.4.3 Fibre Channel FC-BB Background 829 ANSI T11 FC-BB Standards [FCBB] specifies how ARs may be connected 830 across a wide area. FC-BB is specifies a FC-BBW device that allows FC 831 Switches to be connected to a FC-BBW device B_Port. The FC-BBW device 832 has an interface to the wide area. More than one FC-BBW device may be 833 connected to the wide area. Fig. 6.4.4 shows an example of the FC-BB 834 Architecture showing an ATM Network. Currently, SONET is also 835 specified in [FCBB]. In future, Gigabit Ethernet will be specified. 836 FC-BB2 charter clearly states that any IETF protocol specified for 837 carrying FC over IP-based network will be leveraged. It is therefore 838 the intent of the FCIP specification to consider the FC-BB and FC-BB2 839 architectures while drawing this specification. 841 _______ _______ 842 | | | | 843 | AR #1 |--- | AR #4 | 844 |_______| | ______ ________ ______ |_______| 845 __|_ __ | | | | | | ___|___ 846 | BSW 1 |---|FC-BBW|--| IP |--|FC-BBW|--| BSW 4 | 847 |_______| |______| | Network| |______| |_______| 848 | | 849 -------- 850 ______ | | ______ 851 ______ | | | | | | _______ 852 | BSW 2|---|FC-BBW|-----| |---|FC-BBW|---| BSW 3 | 853 |______| |______| |______| |_______| 854 ________ | ___|___ 855 | | | | | 856 | AR #2 |__| | AR #3 | 857 |________| |_______| 859 Fig. 6.4.4 Example Network showing an FC-BB Architecture 861 6.4.4 Introduction to FCIP Protocol 863 The purpose of the FCIP specification is to specify a standard way of 864 encapsulating FC frames over TCP/IP and to describe mechanisms that 865 allow islands of FC SANs to be interconnected over IP-based networks. 866 FC over TCP/IP relies on IP-based network services to provide the 867 connectivity between the SAN islands over LANs, MANs, or WANs. The 868 FC over TCP/IP specification relies upon TCP for congestion control 869 and management and upon both TCP and FC for data error and data loss 870 recovery. FC over TCP/IP treats all classes of FC frames the same -- 871 as datagrams. Any FC concerns arising from tunneling FC traffic over 872 an IP network, including security, data integrity (loss), congestion, 873 and performance. This will be accomplished, where appropriate, by 874 utilizing the existing IETF-specified suite of protocols. 876 A fundamental assumption made in this specification is that the FC 877 traffic is carried over the IP network in such a manner that the FC 878 fabric and all FC devices on the fabric are unaware of the fact. 879 This means that the FC datagrams must be delivered in such time as to 880 comply with existing FC specifications. The FC traffic may span 881 LANs, MANs and WANs, so long as this fundamental assumption is 882 adhered to. 884 FC operates at Gigabit speeds. This specification will be written 885 such that FC traffic may be transported over an IP backbone that has 886 been engineered to have equivalent or better bit-error-rate (BER) and 887 line speed as the Fibre Channel environments being bridged. While 888 the tunneling of Fibre Channel traffic over other IP networks not so 889 engineered is not precluded, the above environment is an important 890 one, and this specification has been written so that to optimize for 891 such traffic, while not over-burdening other configured IP networks. 893 All FCIP protocol devices are peers and communicate using TCP/IP. 894 Each FCIP device behaves like a TCP end-node from the perspective of 895 the IP-based network. That is, these devices do not perform IP 896 routing or IP switching but simply forward FC frames. 898 There is no requirement for an FCIP device to establish a login with 899 a peer before communication begins. However, FCIP devices may 900 authenticate the IP packet before accepting it using the IPSec 901 protocols. Each IP datagram is treated independently and an FCIP 902 device receiver simply listens to the appropriate socket value 903 contained in the TCP header. 905 Each FCIP device may be statically or dynamically configured with a 906 list of IP addresses corresponding to all the participating FCIP 907 devices. Dynamic discovery of participating FCIP devices may be 908 performed using Internet protocols such as LDAP, DHCP or other 909 discovery protocols. It is outside the scope of this specification 910 to describe any static or dynamic scheme for participating FCIP 911 device IP address discovery. 913 Discovery of FC addresses (accessible via the FCIP device) is 914 provided by techniques and protocols within the FC architecture. 915 These techniques and protocols are described in Fibre Channel ANSI 916 standards [T11]. The FCIP device does not participate in the 917 discovery of FC addresses. Routing in the IP plane and the FC plane 918 are largely independent. 920 The exact path (route) taken by an FC over TCP/IP encapsulated packet 921 follows the normal procedures of routing any IP packet. From the 922 perspective of the FCIP devices this communication is between only 923 two FCIP devices for any given packet. 925 An FCIP device may send FC encapsulated TCP/IP packets to more than 926 one FCIP device. However, these encapsulated packets are treated as 927 separate instances and are not correlated in any way by the FCIP 928 protocol devices. The source FCIP device routes its packets based on 929 the 3-byte FC destination Address Identifier (D_ID) contained in each 930 FC frame. 932 An IP packet may make use of the IPSec protocol to provide secure 933 communications across the IP-based network. 935 Any re-ordering of data link frames due to MTU fragmentation will be 936 recovered in accordance with a normal TCP reliable delivery behavior. 938 Any re-ordering of FC frames due to IP packet re-ordering will be 939 resolved via the standard TCP reliable delivery behavior. 941 FCIP relies on both TCP error recovery mechanism and normal FC 942 recovery mechanisms to detect and recover from data loss due to any 943 loss of IP packets. 945 FC over TCP/IP encapsulated IP packets shall indicate the use of the 946 Premium Service in the DSCP bits in the IP header. 948 The TCP layer in the sending FCIP device shall package each FC frame 949 handed down by the FC layer into a TCP segment and set the PSH 950 control flag in the TCP header to ensure that the entire FC frame is 951 sent in one TCP segment. If the FC frame cannot be packaged in one 952 TCP segment (e.g. the FC frame size is greater than TCP MSS), the 953 last part of the FC frame must occupy one TCP segment and the PSH of 954 that segment must be set. 956 6.5 iFCP, mFCP and iSNS 958 The iFCP, mFCP and iSNS protocols are elements of a framework for the 959 implementation of Fibre Channel fabric capabilities on an IP network. 960 These protocols provide the technology for fabric implementation 961 using TCP and IP routing and switching elements in place of fibre 962 channel components. 964 The goals of the framework are to: 966 a) Support the subset of fabric services required by fibre channel 967 storage devices, 968 b) Produce implementations that run at the speed and latency of 969 gigabit IP transports. 970 c) Define the new interfaces to be standardized. 971 d) Identify the interfaces to existing storage standards. 973 The framework permits the transparent attachment of Fibre Channel 974 storage devices to an IP-based fabric by means of lightweight 975 gateways or edge switches. 977 This transparency is achieved through: 979 a) A process for efficiently re-mapping N_PORT addresses embedded in 980 FC frames between the fibre channel and IP network address 981 spaces. 982 b) Provisions for intercepting and emulating the fabric services 983 required by an FCP device. 985 iSNS, the companion name service protocol, has been specially 986 tailored to support both the fibre channel and iSCSI naming models. 988 The following section contains a brief summary of the architecture. 989 The description assumes that the reader is familiar with basic Fibre 990 Channel concepts. In that regard, the material in section 8 may be 991 helpful. 993 6.5.1 Overview of the IP Storage Fabric Architecture 995 In an IP Storage fabric, a fibre channel device is attached to the 996 network through an F_PORT interface that is part of an edge switch 997 or gateway. To the attached device, the network appears as a fibre 998 channel fabric. 1000 N_PORT to N_PORT communications that traverse a TCP/IP or UDP 1001 network require the intervention of the mFCP or iFCP protocol layer 1002 in the gateway. This is done through the following operations on 1003 Fibre Channel frames: 1005 a) Map addresses embedded in the fibre channel frame header between 1006 the fibre channel and IP address spaces. 1007 b) Service requests for fabric-supplied link services addressed to 1008 one of the well-known fibre channel N_PORT addresses. These are 1009 handled entirely within the IP Storage Fabric. 1010 c) Generate special control frames in response to certain link 1011 service requests normally processed by a peer N_PORT. These 1012 require intervention by the sending and receiving iFCP layers in 1013 order to modify and process the frame payloads. 1014 d) Encapsulate frames for injection into the IP network and de- 1015 encapsulate frames received from the IP network. 1016 e) Direct de-encapsulated frames to the appropriate N_PORT. 1018 6.5.2 iSNS _ the Storage Naming Service 1020 The iSNS protocol is designed to provide the name services required 1021 by fibre channel devices. In addition, since many storage objects 1022 are independent of the transport protocol, iSNS has been extended to 1023 support iSCSI as well. 1025 7. Fibre Channel Network Overview 1027 This section contains a brief discussion of the fibre channel 1028 concepts needed to understand the architectures described in this 1029 document. The reader is advised to consult the documents in section 1030 10 for a thorough treatment of the technology. 1032 7.1 The Fibre Channel Network 1034 The fundamental entity in fibre channel is the fibre channel 1035 network. As shown in the diagram below, a fibre channel network is 1036 comprised of the following elements: 1038 a) N_PORTs -- The end points for fibre channel traffic, 1039 b) FC Devices _ The fibre channel devices to which the N_PORTs 1040 provide access. 1041 c) F_PORTs -_ The ports within a fabric that provide fibre channel 1042 attachment for an N_PORT, 1043 d) The fabric infrastructure for carrying frame traffic between 1044 N_PORTs, 1045 e) Within the fabric, a set of auxiliary services and a name service 1046 for device discovery and network address resolution. 1048 Fibre Channel Network 1049 +--------+ +--------+ +--------+ +--------+ 1050 | FC | | FC | | FC | | FC | 1051 | Device | | Device |<-------->| Device | | Device | 1052 |........| |........| |........| |........| 1053 | N_PORT | | N_PORT | | N_PORT | | N_PORT | 1054 +---+----+ +----+---+ +----+---+ +----+---+ 1055 | | | | 1056 +---+----+ +----+---+ +----+---+ +----+---+ 1057 | F_PORT | | F_PORT | | F_PORT | | F_PORT | 1058 +========+===+========+==========+========+==+========+==== 1059 | Fabric | 1060 | & | 1061 | Fabric Services | 1062 +-----------------------------------------------------+ 1064 The following sections describe the internals of a fibre channel 1065 fabric and give an overview of the fibre channel communications 1066 model. 1068 7.1.1 Multi-Switch Fibre Channel Fabric 1070 The internals of a multi-switch fibre channel fabric are shown 1071 below. 1073 Fibre Channel Fabric Internals 1074 +----------+ +----------+ 1075 | FC | | FC | 1076 | Device | | Device | 1077 |..........| |..........| Fibre Channel 1078 | N_PORT |<-------->| N_PORT | Device Domain 1079 +----+-----+ +-----+----+ 1080 | | 1081 +----+-----+ +-----+----+ 1082 | F_PORT | | F_PORT | 1083 ==========+==========+==========+==========+============== 1084 | FC | | FC | 1085 | Switch | | Switch | 1086 +----------+ +----------+ Fibre Channel 1087 |Inter- | |Inter- | Fabric 1088 |Switch | |Switch | 1089 |Interface | |Interface | 1090 +-----+----+ +-----+----+ 1091 | | 1092 | | 1093 +-----+----+----------+-----+----+ 1094 |Inter- | |Inter- | 1095 |Switch | |Switch | 1096 |Interface | |Interface | 1097 +----------+ +----------+ 1098 | FC Switch | 1099 | | 1100 +--------------------------------+ 1102 The interface between switch elements is either proprietary or a 1103 standards-compliant E_PORT interface described by the FC-SW2 1104 specification. 1106 7.2 Fibre Channel Layers and Link Services 1108 Fibre channel consists of the following layers: 1110 FC0 -- The interface to the physical media, 1111 FC1 _- The encoding and decoding of data and out-of-band physical 1112 link control information for transmission over the physical media, 1113 FC2 _- The transfer of frames, sequences and exchanges comprising 1114 protocol information units. 1115 FC3 _- Common Services, 1116 FC4 _- Application protocols, such as FCP, the fibre channel SCSI 1117 protocol. 1119 In addition to the layers defined above, fibre channel defines a set 1120 of auxiliary operations, some of which are implemented within the 1121 transport layer fabric, called link services. These are required to 1122 manage the fibre channel environment, establish communications with 1123 other devices, retrieve error information, perform error recovery 1124 and other similar services. Some link services are executed by the 1125 N_PORT. Others are implemented internally within the fabric. These 1126 internal services are described in the next section. 1128 7.2.1 Fabric-Supplied Link Services 1130 Servers internal to the fabric handle certain classes of Link 1131 Service requests. The servers appear as N_PORTS located at well- 1132 known N_PORT fabric addresses. Service requests use the standard 1133 fibre channel mechanisms for N_PORT-to-N_PORT communications. 1135 All fabrics must provide the following services: 1137 Fabric F_PORT server _ Services an N_PORT request to access the 1138 fabric for communications. 1140 Fabric Controller -- Provides state change information to other 1141 N_PORTS. Used to inform other FC devices when an N_PORT exits or 1142 enters the fabric. 1144 Directory/Name Server _ Allows N_PORTs to register information 1145 in a database or retrieve information about other N_PORTs. 1147 The following optional services are defined: 1149 Broadcast Address/Server _- Transmits single-frame, class 3 1150 sequences to all N_PORTs. 1152 Time Server _- Intended for the management of fabric-wide 1153 expiration timers or elapsed time values and is not intended for 1154 precise time synchronization. 1156 Management Server _ Collects and reports management information, 1157 such as link usage, error statistics, link quality and similar 1158 items. 1160 Quality of Service Facilitator _ For fabric-wide bandwidth and 1161 latency management. 1163 7.3 Fibre Channel Devices 1165 A fibre channel device has one or more fabric-attached N_PORTs. The 1166 device and its N_PORTs have the following associated identifiers: 1168 a) A world-wide unique identifier for the device, 1169 b) A world-wide unique identifier for each N_PORT attached to the 1170 device, 1171 c) For each N_PORT, a fabric-assigned N_PORT fabric address provided 1172 when the device is granted fabric access. This address is unique 1173 within the scope of the fabric. 1175 Information about a fibre channel device, such as the fibre channel 1176 addresses and world wide names of its N_PORTs, can be discovered 1177 through the appropriate name service queries. 1179 7.4 Fibre Channel Information Elements 1181 The fundamental element of information in fibre channel is the 1182 frame. A frame consists of a fixed header and up to 2112 bytes of 1183 payload having the structure described in section 74.4.1. The 1184 maximum frame size that may be transmitted between a pair of fibre 1185 channel devices is negotiable up to the payload limit, based on the 1186 size of the frame buffers in each fibre channel device and the MTU 1187 supported by the fabric. 1189 Operations involving the transfer of information between N_PORT 1190 pairs are performed through exchanges. In an exchange, information 1191 is transferred in one or more ordered series of frames referred to 1192 as sequences. 1194 Within a sequence, frames flow from the sequence originator to the 1195 sequence recipient. Control information within the frame: 1197 a) Delimits sequence boundaries, 1198 b) Identifies the position of a frame within a sequence, 1199 c) Provides for the initiation of a new sequence reversing the 1200 direction of data flow when required by the upper layer protocol. 1202 Within this framework, an upper layer protocol is defined in terms 1203 of transactions carried by exchanges. Each transaction, in turn, 1204 consists of protocol information units, each of which is carried by 1205 an individual sequence within an exchange. 1207 7.4.1 Fibre Channel Frame Format 1209 A fibre channel frame consists of the payload and a header 1210 containing the control information necessary to route frames between 1211 N_PORTs and manage exchanges and sequences. The following diagram 1212 gives a highly simplified view of the frame. 1214 Fibre Channel Frame Format 1215 +-----+-----------------------+<----+ 1216 | | Destination N_PORT | | 1217 | | Fabric Address (D_ID) | | 1218 | | (24-bits) | | 1219 +-----+-----------------------+ 24-byte 1220 | | Source N_PORT | Frame 1221 | | Fabric Address (S_ID) | Header 1222 | | (24 bits) | | 1223 +-----+-----------------------+ | 1224 | Control information | | 1225 | for exchange management, | | 1226 | IU segmentation and | | 1227 | re-assembly | | 1228 +-----------------------------+<----+ 1229 | | 1230 | Frame payload | 1231 | (0 _ 2112 bytes) | 1232 | | 1233 | | 1234 | | 1235 +-----------------------------+ 1237 The source and destination N_PORT fabric addresses are embedded in 1238 the S_ID and D_ID fields respectively. 1240 7.5 Fibre Channel Transport Services 1242 The fibre channel standard defines the following classes of service 1243 provided by a fabric implementation: 1245 Class 1 _ A dedicated physical circuit connecting two N_PORTs. 1247 Class 2 _ A frame-multiplexed connection with end-to-end flow 1248 control and delivery confirmation. 1250 Class 3 _ A frame-multiplexed connection with no provisions for end- 1251 to-end flow control or delivery confirmation. 1253 For class 2 or class 3 service, the fabric is not required to 1254 preserve frame ordering. 1256 Class 3 service is equivalent to UDP or IP datagram service. Fibre 1257 channel storage devices using this class of service rely on the ULP 1258 implementation to detect and recover from transient device and 1259 transport errors. 1261 In addition to the above services, fabrics may implement additional 1262 quality of service policies within the framework of class 2 or class 1263 3 delivery mechanisms. 1265 7.6 N_PORT to N_PORT Communication 1267 An N_PORT joins the fabric and establishes a session with another 1268 N_PORT by invoking the following series of services: 1270 a) F_PORT login _- The device invokes the fabric login service to 1271 register its presence on the fabric and obtain an N_PORT fabric 1272 address. 1273 b) Name Service Lookup - The device obtains the N_PORT fabric 1274 address of another device through a name service query. 1275 c) N_PORT login - The device issues a port login request to 1276 establish an N_PORT-to-N_PORT session. 1277 d) Process Login _ The device performs a process login to establish 1278 a ULP session with a peer process on the remote N_PORT. 1280 An N_PORT issues a corresponding set of logout requests to gracefully 1281 terminate the ULP and N_PORT sessions and fabric login. 1283 8. Definitions 1285 Fabric _ A network interconnecting devices that implement the Fibre 1286 Channel communications model defined in the FC-FS standard. A fabric 1287 may be implemented in the IP framework by means of the protocols 1288 discussed in this document. 1290 FC-2 _ The Fibre Channel transport services layer described in the 1291 FC-FS specification. 1293 FCP Portal - An IP-addressable entity representing the point at 1294 which an iFCP or mFCP node is attached to the IP network. 1296 F_PORT - The interface through which an N_PORT is attached to a 1297 fibre Channel fabric. 1299 N_PORT _ An iFCP or Fibre Channel entity representing the interface 1300 to Fibre Channel device functionality. This interface implements the 1301 Fibre Channel N_PORT semantics specified in the FC-FS standard [FC- 1302 FS]. 1304 9. Security Considerations 1306 Security considerations for IP Storage protocols are driven not only 1307 by the same general concerns expressed regarding other Internet 1308 application protocols, but also by the historical expectations of 1309 storage users. IP Storage emulates SCSI, and there is a risk that 1310 users will treat it as such, ignoring the potential security issues 1311 introduced by this new technology. 1313 Parallel SCSI interconnections between computer systems and storage 1314 devices inherently rely on the physical security of the computer 1315 equipment room. It is easy to perform a security audit for such a 1316 network; you determine connectivity by following where the wire 1317 goes, verify addressing by noting the value dialed into each 1318 device's selector switch, and ascertain privacy by confirming there 1319 are no unauthorized connections. 1321 The introduction of SCSI over Fibre Channel removed the distance 1322 limitations that kept parallel SCSI within the equipment room, and 1323 active SAN devices such as repeater hubs and switches removed SCSI's 1324 restriction to a linear bus topology. Even so, security 1325 considerations for a Fibre Channel SAN often still relies on 1326 physical isolation of the network, supplemented by configuration 1327 features such as zoning, the Fibre Channel equivalent of Virtual 1328 LANs. It has been said that the relatively limited deployment of 1329 Fibre Channel SAN connections (relative to the ubiquitous presence 1330 of the LAN,) gives the SAN a false patina of _security through 1331 obscurity._ 1333 Such assumptions are incompatible with an underlying network 1334 architecture such as that of the Internet, which inherently provides 1335 ubiquitous connectivity across both private and public network 1336 segments. Perhaps the _worst case_ scenario would be perfect 1337 emulation of SCSI-attached storage, where some or all of the 1338 underlying connectivity traversed a public IP network. In that 1339 situation, the end-station behavior would be that of a parallel SCSI 1340 system which assumes underlying physical security, while the network 1341 behavior would be that of an open transport environment that defers 1342 any layered security needs to the end-stations. 1344 A partial solution may be obtained by providing enhanced security 1345 services at the interfaces from the existing storage network to the 1346 IP storage network. There, services such as encryption and 1347 authentication may be applied to the non-physically secure portion 1348 of the path, without requiring end-station changes. 1350 Overall security for such a solution may be no better than that of a 1351 SAN presumed to be physically secure, but at least it will not be 1352 perceived as worse. 1354 Link-level security need not be the only solution. In many 1355 applications, privacy of data transmission across the network may be 1356 less significant an issue than controlling who accesses the storage 1357 resources. In such situations, access-control solutions such as the 1358 resource login provided by iSCSI can add value. 1360 Finally, it should be noted that new security concerns may be raised 1361 merely by allowing SANs to be scaled to larger size and complexity. 1362 Introducing many milliseconds of WAN delay into storage protocols 1363 accustomed to microseconds of latency may expose previously 1364 undetected behavioral problems. Discovery algorithms which work 1365 perfectly for fifteen target devices, may fail spectacularly with 1366 fifteen hundred. Practices that are acceptable in small systems, 1367 such as static assignment of passwords to resources, may become 1368 unacceptable in large ones, where devices are frequently added and 1369 removed. And malicious behavior, such as _spoofing_ of Fibre Channel 1370 source addresses, take on new significance when the malicious device 1371 is located in some remote SAN, who's operational capabilities and 1372 management policies may be different than your own. 1374 10. References 1376 RFC2026 Bradner, S., "The Internet Standards Process -- Revision 3", 1377 BCP 9, RFC 2026, October 1996. 1379 RFC2119 Bradner, S., "Key words for use in RFCs to Indicate 1380 Requirement Levels", BCP 14, RFC 2119, March 1997. 1382 SCSI-3 SCSI-3 Standards Architecture (Diagram) 1383 http://www.t11.org/t10/scsi-3.htm 1385 FCP American National Standard of Accredited Standards Committee 1386 NCITS, "Fibre Channel Protocol for SCSI, Second Version 1387 (FCP-2) " ftp://ftp.t11.org/t10/drafts/fcp2/fcp2r04b.pdf 1389 CAM American National Standard of Accredited Standards Committee 1390 X3, "SCSI-2 Common access method transport and SCSI 1391 interface module". ftp://ftp.t11.org/t10/drafts/cam/cam- 1392 r12b.pdf 1394 T11 NCITS 321-200x (ANSI) T11/Project 1305-D/Rev 4.8 "Fibre 1395 Channel Switch-Fabric-2", (FC-SW-2) October 29, 2000 1396 (www.t11.org) 1398 FCBB NCITS T11/Project 1238-D/Rev4.7 "Fibre Channel Backbone", 1399 (FC-BB) June 8, 2000 (www.t11.org) 1401 SPC-2 NCITS T10/Project 1236-D/Rev 18, "SCSI Primary Commands - 2 1402 (SPC-2)", 21 May 2000. 1404 FCoverIP Rajagopal, M., Bhagwat, R., Rodriguez, E., Chau, V., 1405 Berman, S., Wilson, S., O'Donnell, M., Carlson, C., "Fibre 1406 Channel Over TCP/IP (FCIP)", draft-ietf-ips-fcovertcpip- 1407 00.txt, October 2000. 1409 iFCP Mullendore, R., Monia, C., Tseng, J., "iFCP - A Protocol for 1410 Internet Fibre Channel Storage Networking", draft-monia-ips- 1411 iFCP-00.txt, November 2000. 1412 mFCP Mullendore, R., Monia, C., Tseng, J., "mFCP - Metro FCP 1413 protocol for IP Networking", November 2000. 1415 iSCSI Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P., 1416 Haagens, R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI", 1417 draft-ietf-ips-iscsi-00.txt, November, 2000. 1419 iSCSI-REQ Haagens, R., "iSCSI (Internet SCSI) Requirements", draft- 1420 haagens-ips-iscsireqs-00.txt, July 2000. 1422 RFC1718 IETF Secretariat, Malkin, G., "The Tao of IETF", RFC 1718, 1423 CNRI, Xylogics, Inc., November 1994. 1425 RFC2418 Bradner, S., "IETF Working Group Guidelines and Procedures", 1426 RFC 2418, Harvard University, September 1998. 1428 RFC1157 Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 1429 Simple Network Management Protocol", STD 15, RFC 1157, May 1430 1990. 1432 RFC2578 McCloghrie, K., Perkins, D. and J. Schoenwaelder, 1433 "Structure of Management Information Version 2 (SMIv2)", STD 1434 58, RFC 2578, April 1999. 1436 RFC2837 Teow, K. S., "Definitions of Managed Objects for the Fabric 1437 Element in Fibre Channel Standard", RFC 2837, May 2000. 1439 RFC2625 Rajagopal, M., Bhagwat, R., and Rickard, W., "IP and ARP 1440 over Fibre Channel", RFC 2625, June 1999. 1442 FCMIB Carlson, M., Bowlby, G., and Hu, L., "A Framework for Fibre 1443 Channel MIBs", draft-ietf-ipfc-mib-framework-03.txt, July 1444 2000. 1446 FIMIB Blumenau, S., "Fibre Channel Management Framework 1447 Integration MIB", draft-ietf-ipfc-fcmgmt-int-mib-04.txt, May 1448 2000. 1450 RFC2143 Elliston, B., "Encapsulating IP with the Small Computer 1451 System Interface", RFC 2143, May 1997. 1453 RFC760 Information Sciences Institute, "Internet Protocol", RFC 1454 760, January 1980. 1456 RFC761 Information Sciences Institute, "Transmission Control 1457 Protocol", RFC 761, January 1980. 1459 RFC2960 Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1460 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla. M., Zhang, 1461 L., Paxson, V., "Stream Control Transmission Protocol", RFC 1462 2960, October 2000. 1464 RFC1180 Socolofsky, T., and Kale, C., "A TCP/IP Tutorial", RFC 1180, 1465 January 1991. 1467 RFC813 Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 1468 813, July 1982. 1470 RFC879 Postel, J., "The TCP Maximum Segment Size and Related 1471 Topics", RFC 879, November 1983. 1473 RFC955 Braden, R., "Towards a Transport Service for Transaction 1474 Processing Applications", RFC 955, September 1985. 1476 RFC962 Padlipsky, M., "TCP-4 Prime", RFC 962, November 1985. 1478 RFC2001 Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 1479 Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1480 1997. 1482 RFC2101 Carpenter, B., Crowcroft, J., and Rekhter, Y., "IPv4 Address 1483 Behaviour Today", RFC 2101, February 1997. 1485 RFC2330 Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1486 "Framework for IP Performance Metrics", RFC 2330, May 1998. 1488 RFC2415 Poduri, K., and Nichols, K., "Simulation Studies of 1489 Increased Initial TCP Window Size", RFC 2415, September 1490 1998. 1492 RFC2414 Allman, M., Floyd, S., and Partridge, C., "Increasing TCP's 1493 Initial Window", RFC 2414, September 1998. 1495 RFC2581 Allman, M., Paxson, V., and Stevens, W., "TCP Congestion 1496 Control", RFC 2581, April 1999. 1498 RFC2151 Kessler, G. and Shepard, S., "A Primer On Internet and 1499 TCP/IP Tools and Utilities", RFC 2151, June 1997. 1501 RFC2398 Parker, S. and Schmechel, C., "Some Testing Tools for TCP 1502 Implementors", RFC 2398, August 1998. 1504 RFC2140 Touch, J., "TCP Control Block Interdependence", RFC 2140, 1505 April 1997. 1507 X500 CCITT Recommendation X.500, "The Directory: Overview of 1508 Concepts, Models and Service", 1988. 1510 RFC2251 Wahl, M., Howes, T. and Kille, S., "Lightweight Directory 1511 Access Protocol (v3)", RFC 2251, December 1997. 1513 RFC2830 Hodges, J., Morgan, R. and Wahl, M., "Lightweight Directory 1514 Access Protocol (v3): Extension for Transport Layer 1515 Security", RFC 2830, May 2000. 1517 RFC2256 Wahl, M., "A Summary of the X.500(96) User Schema for use 1518 with LDAPv3", RFC 2256, December 1997. 1520 RFC2255 Howes, T. and Smith, M., "The LDAP URL Format", RFC 2255, 1521 December 1997. 1523 RFC2254 Howes, T., "The String Representation of LDAP Search 1524 Filters", RFC 2254, December 1997. 1526 RFC2252 Wahl, M., Coulbeck, A., Howes, T. and Kille, S., 1527 "Lightweight Directory Access Protocol (v3): Attribute 1528 Syntax Definitions", RFC 2252, December 1997. 1530 RFC2247 Kille, S., Wahl, M., Grimstad, A., Huber, R. and Sataluri, 1531 S., "Using Domains in LDAP/X.500 Distinguished Names", RFC 1532 2247, January 1998. 1534 RFC1591 Postel, J., "Domain Name System Structure and Delegation", 1535 RFC 1591, March 1994. 1537 SNS Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage 1538 Name Service", draft-tseng-ips-isns-00.txt, October 2000. 1540 RFC2914 Floyd, S. "Congestion Control Principles", RFC 2914, BCP 41, 1541 September 2000. 1543 RFC2979 Freed, N., "Behavior of and Requirements for Internet 1544 Firewalls", RFC 2979, October 2000. 1546 RFC1631 Egevang, K. and Francis, P., "The IP Network Address 1547 Translator (NAT)", RFC 1631, May 1994. 1549 RFC2663 Srisuresh, P. and Holdrege, M., "IP Network Address 1550 Translator (NAT) Terminology and Considerations", RFC 2663, 1551 August 1999. 1553 RFC1918 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. 1554 and Lear, E., "Address Allocation for Private Internets", 1555 RFC 1918, BCP 5, February 1996. 1557 RFC2050 Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and 1558 Postel, J., "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 1559 RFC 2050, BCP 12, November 1996. 1561 RFC2766 Tsirtsis, G. and Srisuresh, P., "Network Address Translation 1562 - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 1564 RFC2504 Guttman, E., Leong, L. and Malkin, G., "Users' Security 1565 Handbook", RFC 2504, February 1999. 1567 RFC2411 Thayer, R., Doraswamy, N. and Glenn, R., "IP Security 1568 Document Roadmap", RFC 2411, November 1998. 1570 RFC2828 Shirey, R., "Internet Security Glossary", RFC 2828, May 1571 2000. 1573 RFC2709 Srisuresh, P., "Security Model with Tunnel-mode IPsec for 1574 NAT Domains", RFC 2709, October 1999. 1576 RFC2401 Kent, S. and Atkinson, R., "Security Architecture for the 1577 Internet Protocol", RFC 2401, November 1998. 1579 RFC1511 Linn, J., "Common Authentication Technology Overview", RFC 1580 1511, September 1993. 1582 RFC2402 Kent, S. and Atkinson, R., "IP Authentication Header", RFC 1583 2402, November 1998. 1585 RFC2406 Kent, S. and Atkinson, R., "IP Encapsulating Security 1586 Payload (ESP)", RFC 2406, November 1998. 1588 RFC1630 Berners-Lee, T., "Universal Resource Identifiers in WWW", 1589 RFC 1630, June 1994. 1591 RFC1738 Berners-Lee, T., Masinter, L. and McCahill, M., "Uniform 1592 Resource Locators (URL)", RFC 1738, December 1994. 1594 RFC2624 Shepler, S., "NFS Version 4 Design Considerations", RFC 1595 2624, June 1999. 1597 RFC2224 Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. 1599 NFS4 Shepler, S., Beame, C., Callaghan, B., Eisler, M., Noveck, 1600 D., Robinson, D. and Thurlow, R., "NFS version 4 Protocol", 1601 draft-ietf-nfsv4-07.txt, June 2000. 1603 11. Acknowledgments 1605 Thanks to Randy Haagens for text taken from the iSCSI requirements 1606 document. 1608 12. Author's Addresses 1610 Mark A. Carlson 1611 Sun Microsystems, Inc. 1612 Email: Mark.Carlson@Sun.COM 1614 Satish Mali 1615 StoneFly Networks 1616 Email: satish@stoneflynetworks.com 1618 Milan Merhar 1619 Pirus Networks 1620 Email: milan@pirus.com 1621 Charles Monia 1622 Nishan Systems 1623 Email: cmonia@nishansystems.com 1625 Murali Rajagopal 1626 LightSand Communications 1627 Email: muralir@lightsand.com 1628 Appendix A: Existing Internet Standards and Procedures 1630 A.1 IETF and RFC overview 1632 Various working groups formed out of interested parties define 1633 Internet Protocols. The Internet Engineering Task Force (IETF) forms 1634 these working groups. The IETF is a large open international 1635 community of network designers, operators, vendors, and researchers 1636 concerned with the evolution of the Internet architecture and the 1637 smooth operation of the Internet. The spirit of IETF is explained in 1638 _The Tao Of IETF_.(To borrow from _The Tao of IETF_, the mission of 1639 IETF is 1641 * Identifying, and proposing solutions to, pressing operational and 1642 technical problems in the Internet, 1643 * Specifying the development or usage of protocols and the near-term 1644 architecture to solve such technical problems for the Internet 1645 * Making recommendations to the Internet Engineering Steering Group 1646 (IESG) regarding the standardization of protocols and protocol 1647 usage in the Internet 1648 * Facilitating technology transfer from the Internet Research Task 1649 Force (IRTF) to the wider Internet community; and 1650 * Providing a forum for the exchange of information within the 1651 Internet community between vendors, users, researchers, agency 1652 contractors and network managers. 1654 The IETF working group members interact with each other and produce 1655 documents called _Request For Comments_. These RFCs are now 1656 subdivided into FYIs (For Your Information also know as 1657 _Informational_) and STDs (Standard). The _Informational_ RFC sub- 1658 series provides overviews and topics that are introductory. This 1659 document, for example is an Informational RFC. STD RFCs identify 1660 those RFCs that specify Internet standards. 1662 Every RFC, including FYIs and STDs, have an RFC number by which they 1663 are indexed and by which they can be retrieved. FYIs and STDs have 1664 FYI numbers and STD numbers, respectively, in addition to RFC 1665 numbers 1667 A.2 RFC summary: 1669 The Internet Engineering Task Force (IETF) is responsible for 1670 developing and reviewing specifications intended as Internet 1672 Standards. IETF activities are organized into working groups (WGs). 1673 RFC 2418 describes the guidelines and procedures for formation and 1674 operation of IETF working groups [RFC2418]. 1676 Because there are so many RFCs, a summary is provided for RFCs by an 1677 RFC itself. You will find that generally every n99 RFC provides a 1678 summary of RFCs from n00 to n99. Here n99 stands for 1 to 27. 1679 Therefore, RFC 2799 will provide summary for all RFCs from 2700 to 1680 2798. Also most of the RFCs that end in 00 provide a one-line 1681 summary up to that RFC. Thus, 2700 will be one line summary for all 1682 RFCs from 2600 to 2699. 1684 A.3 Management of TCP/IP based devices: 1686 Management of TCP/IP based networked element in enterprises is 1687 routinely done using Simple Network Management Protocol (SNMP) 1688 [RFC1157]. This SNMP protocol allows any networked entity that 1689 supports SNMP, to be managed using a standardized method. The 1690 parameters that can be managed and monitored for this network entity 1691 is defined by another standard called the Structure of Management 1692 Information Version 2 (SMIv2)[RFC2578] that defines a collection of 1693 managed objects, residing in a virtual information store, termed the 1694 Managed Information Base (MIB). Every vendor normally supports a 1695 subset of the standard MIB and also provides a vendor dependant 1696 private MIB. This private MIB being written in standard format can 1697 be used by SNMP management software. MIBs are proposed from time to 1698 time, and added to the standard MIBs to have a generic way of 1699 managing generic parameters and interfaces. 1701 A.4 Fibre Channel related standards: 1703 [RFC2837] defines the objects for managing the operations of the 1704 Fabric Element portion of the Fibre Channel Standards. While 1705 [RFC2625] specifies a way of encapsulating IP and Address Resolution 1706 Protocol (ARP) over Fibre Channel and to describes a mechanism(s) 1708 for IP address resolution. A Framework for Fibre Channel MIBs 1709 [FCMIB] discusses technical issues and requirements for the 1710 management information base (MIB) for Fibre Channel and storage 1711 network applications. The Fibre Channel Management Framework 1712 Integration MIB [FIMIB] provides an integrated management 1713 environment to enable interoperability among the various vendors 1714 involved in the Fibre Channel marketplace. [RFC2143] outlines a 1715 protocol for connecting hosts running the TCP/IP protocol suite over 1717 a Small Computer System Interface (SCSI) bus. This RFC defines an 1718 experimental protocol and is not a proposed standard. 1720 For a general discussion of Fibre Channel standards, see section 7 1721 of this document. 1723 A.5 Standards related to TCP and IP: 1725 There are many TCP/IP related RFCs dating back to 1980. The original 1726 RFC that formulated Internet Protocol (IP) is [RFC760]. [RFC761] is 1727 for Transmission Control Protocol (TCP). To get a good TCP/IP bare- 1728 bones overview you might want to start with [RFC1180]. [RFC813] 1729 describes implementation strategies using sliding window protocol. 1730 It presents a field-tested flow control algorithm. [RFC879] 1731 discusses the TCP Maximum Segment Size Option and related topics. 1732 The purpose here is to clarify some aspects of TCP and its 1733 interaction with IP. [RFC869] provides ways of congestion control in 1734 IP/TCP networks. It is suggestive in nature and not a standard. Two 1735 RFCs ([RFC955] and [RFC962]) provide early thoughts on transaction 1736 processing on TCP/IP based networks. 1738 Information about TCP/IP workings are provided in [RFC2001] (TCP 1739 Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery 1740 Algorithms), [RFC2101] (IPv4 Address Behaviour Today), [RFC2330] 1741 (Framework for IP Performance Metrics), [RFC2415] (Simulation 1742 Studies of Increased Initial TCP Window Size), [RFC2414] (Increasing 1743 TCP's Initial Window), [RFC2581] (TCP Congestion Control). A primer 1744 on Internet and TCP/IP Tools and Utilities is provided by [RFC2151] 1745 along with [RFC2398](Some Testing Tools for TCP Implementors). 1746 [RFC2140] provides information about TCP Control Block 1747 Interdependence. 1749 A.6 Standards related to Naming and Discovery topics: 1751 LDAP is used as a directory service for querying and accessing 1752 resources in a networked domain. LDAP can be used as one of the 1753 means to identify iSCSI resources. Another possible method would be 1754 to use a DNS server. A third alternative is to use a Name server 1755 specifically designed for iSCSI. 1757 A.6.1 LDAP: 1759 The Open System Interconnect (OSI) defined a _Directory_ protocol 1760 that provides a powerful infrastructure for the retrieval of 1761 information objects. This infrastructure can be used to do lookups 1762 in white pages, or applications or other informational objects. It 1763 was standardized by CCITT as X.500 [X500].[RFC2251] describes access 1764 to the X.500 Directory while not incurring the resource requirements 1765 of the Directory Access Protocol (DAP). This protocol is 1766 specifically targeted at simple management applications and browser 1767 applications that provide simple read/write interactive access to 1768 the X.500 Directory, and is intended to be a complement to the DAP 1769 itself. 1771 One approach to discovery of iSCSI devices would be to query LDAP 1772 services. 1774 [RFC2830] provides extension for transport layer Security to LDAP 1775 version 3. RFCs that cover other areas of LDAP are [RFC2256] (User 1776 Schema for use with LDAPv3), [RFC2255] (The LDAP URL Format), 1777 [RFC2254] (The String Representation of LDAP Search Filters), 1778 [RFC2252] (Attribute Syntax Definitions), [RFC2247] (Using Domains 1779 in LDAP/X.500 Distinguished Names). 1781 A.6.2 DNS: 1783 DNS (Domain Name Service) is used to find networked nodes using a 1784 name. The DNS server maps this name to an IP address. 1786 The Internet Assigned Numbers Authority (IANA) is the overall 1787 authority for the IP Addresses, the Domain Names, and many other 1788 parameters, used in the Internet. [RFC1591] provides information on 1789 the structure of the names in the Domain Name System (DNS), 1790 specifically the top-level domain names and on the administration of 1791 domains. 1793 It is possible to use DNS as one way to identify iSCSI devices. The 1794 DNS named devices then can be addressed in URLs or other addressing 1795 schemes. 1797 A.6.3 iSCSI Name Server: 1799 There are currently no IETF standards. There is a proposed IETF 1800 standard draft [iSNS] for an iSCSI Name Server that describes one 1801 proposal. 1803 A.7 Flow Control related Standards: 1805 Any IP based storage protocol needs to account for the existing 1806 congestion control mechanisms of the Internet. Internet Protocol 1807 based networks provide congestion control using TCP/IP and are 1808 documented in [RFC2581] and [RFC2001]. The Congestion Control 1809 Principles are explained in [RFC2914]. 1811 A.8 Standards related to Firewall, NAT: 1813 A firewall is a device that is inserting on the path between the 1814 Internet and the internal network and it screens network traffic in 1815 some way, blocking traffic it believes to be inappropriate, 1816 dangerous, or both. 1818 [RFC2979] defines behavioral characteristics of and interoperability 1819 requirements for Internet firewalls. 1821 A NAT (Network Address Translation) is a special purpose router that 1822 generally has a private IP addresses on one interface and a public 1823 IP address on the second interface. The private IP address is mapped 1824 to a public IP address by the NAT, and is managed by using port 1825 numbers. This allows a company to use private IP addresses within 1826 the company and only use a few public IP addresses. An overview 1827 about NAT is documented in [RFC1631]. The terms used in NAT are 1828 provided in [RFC2663]. The private side network address allocation 1829 is provided by [RFC1918]. The public side address allocation guide 1830 is provided by [RFC2050]. [RFC2766] provides information about 1831 translation involved from Ipv4 to Ipv6. 1833 Please note that the firewall functions are disjoint from NAT 1834 functions. Neither implies the other, although, many times, both are 1835 provided by the same device. 1837 iSCSI devices will be accessed through either firewalls or NAT 1838 devices or both. The addressing, naming and discovery schemes should 1839 be designed to work with existing firewalls and NAT devices. 1841 A.9 Security and Authentication related Standards: 1843 IP based storage devices may be available over Internet which may 1844 mean that they are publicly accessible. It is also envisioned that 1845 the IP based connectivity is provided between isolated private SANs. 1846 Security is then a major concern and needs to be addressed at every 1847 level of access. 1849 There are many RFCs related to security. iSCSI will mainly involve 1850 use of IPsec based security. The RFCs provided here may be of 1851 interest to many users as security in an open environment like IP is 1852 very important. 1854 If you want to understand security, you may want to start with 1855 [RFC2504] (Users' Security Handbook). IPsec protocol suite is used 1856 to provide privacy and authentication services at the IP layer. 1857 Several documents are used to describe this protocol suite. The 1858 interrelationship and organization of the various documents covering 1859 the IPsec protocol are discussed in [RFC2411]. The security glossary 1860 is provided by [RFC2828]. 1862 A secure path is established between two Internetworked ends by 1863 encrypting packets between the two ends. This allows complete 1864 privacy of any data that is sent from one end to another. The 1865 establishment of this private channel is called tunneling and is 1866 defined by IPsec standard. [RFC2709] provides the security model for 1867 Tunnel-mode IPsec for NAT domains. 1869 The _Security Architecture for the Internet Protocol_ is provided in 1870 [RFC2401] and specifies the base architecture for IPsec compliant 1871 systems. 1872 Authentication Mechanisms are covered by [RFC1511] (Common 1873 Authentication Technology Overview). 1875 Sending and receiving special secret codes called keys provide 1876 authentication. [RFC2402] provides details of _IP Authentication 1877 Header_. 1879 Encrypting data provides privacy. It is detailed in [RFC2406] (IP 1880 Encapsulating Security Payload (ESP)). 1882 A popular method of providing security is by use of a proxy server. 1883 Devices inside a company, wanting to communicate to outside world 1884 will communicate with the proxy server and the proxy server 1885 translates their requests to outside world. 1887 A.10 Addressing and other Miscellaneous Standards: 1889 One proposed to access ISCSI devices is by using URLs. 1891 Uniform Resource locator (URL) is commonly used as a compact string 1892 representation for a resource available on Internet. The concept of 1893 URL was introduced by the World Wide Web global information 1894 initiative in 1990 and is described in "Universal Resource 1895 Identifiers in WWW", [RFC1630]. The Hypertext Transfer Protocol 1896 (HTTP) is an application-level protocol that is used for 1897 communications between these URL specified resources on Internet. 1898 HTTP is also used as a generic protocol for communication between 1899 user agents and proxies/gateways to other Internet protocols, such 1900 as SMTP, NNTP, FTP, Gopher, and WAIS, allowing basic hypermedia 1901 access to resources available from diverse applications and 1902 simplifying the implementation of user agents. 1904 [RFC1738] specifies the Uniform Resource Locator (URL), the syntax 1905 and semantics of formalized information for location and access of 1906 resources via the Internet. 1908 A.11 Network File related protocols: 1910 Though these protocols are not related to iSCSI or other block data 1911 protocols, they are enumerated here for interested parties. 1913 Network File System (NFS) protocol provides access to shared file- 1914 systems across networks. It is designed to be machine, operating 1915 system, network architecture, and transport protocol independent. 1917 The latest NFS version will be version 4 and the issues in the 1918 design of NFS 4 are provided in [RFC2624]. The NFS Version 4 1919 protocol is described in [NFS4]. [RFC2224] defines 'nfs' as a new 1920 URL scheme. The `nfs' URL will refer to files and directories on NFS 1921 servers using the general URL syntax as per [RFC1738]. 1923 Full Copyright Statement 1925 Copyright (C) The Internet Society 2000. All Rights Reserved. This 1926 document and translations of it may be copied and furnished to 1927 others, and derivative works that comment on or otherwise explain it 1928 or assist in its implementation may be prepared, copied, published 1929 and distributed, in whole or in part, without restriction of any 1930 kind, provided that the above copyright notice and this paragraph 1931 are included on all such copies and derivative works. However, this 1932 document itself may not be modified in any way, such as by removing 1933 the copyright notice or references to the Internet Society or other 1934 Internet organizations, except as needed for the purpose of 1935 developing Internet standards in which case the procedures for 1936 copyrights defined in the Internet Standards process must be 1937 followed, or as required to translate it into languages other than 1938 English. 1940 The limited permissions granted above are perpetual and will not be 1942 revoked by the Internet Society or its successors or assigns. 1944 This document and the information contained herein is provided on an 1945 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1946 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1947 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1948 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1949 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."