INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 PWE3 Internet Draft Moran Roth (Ed.) Document: draft-roth-pwe3-fc-encap-00.txt Ronen Solomon Expires: December 2005 Corrigent Systems Munefumi Tsurusawa KDDI June 2005 Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A Fibre Channel Pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. Table of Contents 1. Specification of Requirements..................................2 2. Motivation.....................................................2 Roth, et al. Expires - December 2005 [Page 1] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 3. Introduction...................................................3 4. Encapsulation..................................................4 4.1. The Control Word..........................................4 4.2. MTU Requirements..........................................5 4.3. Mapping of FC traffic to PW PDU...........................5 4.4. PW failure mapping........................................6 5. Security Considerations........................................7 6. IANA considerations............................................7 7. References.....................................................7 8. Informative references.........................................8 9. Author's Addresses.............................................8 10. Contributing Author Information...............................8 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14] 2. Motivation As metro transport networks migrate to a packet-oriented infrastructure, the PSN is extended in order to allow all services to be transported over a common network infrastructure. This has been accomplished for services such as Ethernet [ETH], Frame Relay [FRAME], ATM [ATM] and SONET/SDH [CEP] services. Another such service, which has yet to be addressed, is the transport of Fibre Channel frames over the PSN. This will allow network service providers to transparently carry Fibre Channel services over the PSN with inherent QoS considerations, along with the above data and TDM services. Transporting of Fibre Channel (FC) frames in a metro area network (MAN) as well as in a wide area network (WAN) to extend a storage area network (SAN) is an essential technology for mission-critical application such as disaster recovery and business continuity. Several solutions for the SAN extension have been proposed by encapsulating the FC frame in the conventional protocols. The former methodologies are the FC over SONET/SDH and the FC over Internet Protocol (FC/IP). The FC/SONET using Generic Framing Procedure (GFP) technology is the most accomplished technology for transporting FC as a channel extender. However, this methodology does not benefit the statistical multiplexing advantage inherently supported by the packet-centric network, which carriers are going to construct in the future. Another method to carry FC across PSN is FC/IP that allows FC frames to be transported through Layer 3 packet networks. FC/IP is based on Roth, et al. Expires - December 2005 [Page 2] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 carrying the FC frames above Layer 3 IP protocol with TCP awareness for reliability and FC performance consideration. With the ongoing transition of service providers migrating into a Layer 2 PSN using MPLS tunneling such as pseudowire technology over the MPLS network, the transportation of FC over the packet switching network can be inherently supported with QoS and performance considerations such as bounded delay and committed rates. 3. Introduction A Fibre Channel Pseudowire (PW) allows FC Protocol Data Units (PDUs) to be carried over an MPLS network. In addressing the issues associated with carrying a FC PDU over an MPLS network, this document assumes that a Pseudowire (PW) has been set up by some means outside of the scope of this document. This MAY be achieved via manual configuration, or using the signaling protocol as defined in [PW- MPLS]. A FC PW emulates a single FC link between exactly two endpoints. This document specifies the emulated PW encapsulation for FC. The following figure describes the reference models which are derived from [RFC3985] to support the FC PW emulated services. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | Native FC service Native FC service Figure 1: PWE3 FC Interface Reference Configuration Roth, et al. Expires - December 2005 [Page 3] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 For the purpose of the discussion in this document PE1 will be defined as the ingress router, and PE2 as the egress router. A layer 2 PDU will be received at PE1, encapsulated at PE1, transported, decapsulated at PE2, and transmitted out on the attachment circuit of PE2. The following reference model describes the termination point of each end of the PW within the PE: +-----------------------------------+ | PE | +---+ +-+ +-----+ +------+ +------+ +-+ | | |P| | | |PW ter| | PSN | |P| | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN | | |y| | | |on | | | |y| | C | +-+ +-----+ +------+ +------+ +-+ | E | | | | | +-+ +-----+ +------+ +------+ +-+ | | |P| | | |PW ter| | PSN | |P| | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN | | |y| | | |on | | | |y| +---+ +-+ +-----+ +------+ +------+ +-+ | | +-----------------------------------+ Figure 2: PW reference diagram The Native Service Processing (NSP) function includes native FC traffic processing that is required either for the proper operation of the FC link, or for the FC frames that are forwarded to the PW termination point. The NSP function is outside of the scope of PWE3 and is defined by [FC-BB]. 4. Encapsulation This specification provides port to port transport of FC encapsulated traffic. The following FC connections are supported over the MPLS network: - N-Port to N-Port - N-Port to F-Port - E-Port to E-Port FC Primitive Signals and FC-Port Login handling by the NSP function within the PE is defined in [FC-BB]. 4.1. The Control Word The Generic PW control word, as defined in "PWE3 Control Word" [PW- CW] MAY be used for FC PW. The structure of the control word is as follows: Roth, et al. Expires - December 2005 [Page 4] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0 0 0 0|FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - Control Word structure for the one-to-one mapping mode The Flags bits are not used for FC. These bits MUST be set to 0 by the ingress PE, and MUST be ignored by the egress PE. The FRG bits are used for PW PDU fragmentation as described in [PW- CW] and [FRAG]. The length field can be used to remove any padding added by the PSN. Its processing must follow the rules defined in [PW-CW]. The use of the sequence number is optional, and the processing must follow the rules as in [PW-CW]. 4.2. MTU Requirements The network MUST be configured with an MTU that is sufficient to transport the largest encapsulation frames. When MPLS is used as the tunneling protocol, for example, this is likely to be 12 or more bytes greater than the largest frame size. The methodology described in [FRAG] MAY be used to fragment encapsulated frames that exceed the PSN MTU. However if [FRAG] is not used then if the ingress router determines that an encapsulated layer 2 PDU exceeds the MTU of the PSN tunnel through which it must be sent, the PDU MUST be dropped. 4.3. Mapping of FC traffic to PW PDU FC frames and Primitive Sequences are transported over the PW. Packet type marking is performed by the NSP in a NSP header, and is outside of the scope of this document. Each FC frame is mapped to a PW PDU, including the SOF delimiter, frame header, CRC field and the EOF delimiter, as shown in figure 4. SOF and EOF frame delimiters are encoded as specified in [FC-BB]. Roth, et al. Expires - December 2005 [Page 5] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-----------------------------------------------+ | SOF Code | Reserved | +---------------+-----------------------------------------------+ | | +----- FC Frame ----+ | | +---------------------------------------------------------------+ | CRC | +---------------+-----------------------------------------------+ | EOF Code | Reserved | +---------------+-----------------------------------------------+ Figure 4 - FC Frame Encapsulation within PW PDU FC Primitive Sequences are encapsulated in a PW PDU containing the encoded K28.5 character, followed by the encoded 3 data characters, as shown below. A PW PDU may contain one or more FC encoded ordered sets. The length field in the CW is used to indicate the packet length when the PW PDU contains a small number of Primitive Sequences. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | K28.5 | Dxx.y | Dxx.y | Dxx.y | +---------------+---------------+---------------+---------------+ | | +---- ----+ | | +---------------+---------------+---------------+---------------+ | K28.5 | Dxx.y | Dxx.y | Dxx.y | +---------------+---------------+---------------+---------------+ Figure 5 - FC Ordered Sets Encapsulation within PW PDU Idle Primitive Signals are carried over the PW in the same manner as Primitive Sequences. Note that in both cases a PE is not required to transport all the ordered sets received. The PE MAY implement repetitive signal suppression functionality. The egress PE extracts the Primitive Sequence and Idle Primitive Signals from the received PW PDU. It continues transmitting the same Ordered set until a FC frame or another Ordered set is received over the PW. 4.4. PW failure mapping Roth, et al. Expires - December 2005 [Page 6] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 PW failure mapping, which are detected through PW signaling failure, PW status notifications as defined in [PW-MPLS], or through PW OAM mechanisms MUST be mapped to emulated signal failure indications. The FC link failure indication is performed by the NSP, as defined by [FC-BB], and is out of the scope of this document. 5. Security Considerations This document specifies only encapsulations, and not the protocols used to carry the encapsulated packets across the PSN. Each such protocol may have its own set of security issues [PW-MPLS] [RFC3985], but those issues are not affected by the encapsulations specified herein. Note that the security of the emulated service will only be as good as the security of the PSN. 6. IANA considerations A new PW type, named "FC Port Mode" is requested from IANA. The next available value of 0x0021 is requested. 7. References [RFC3985] Bryant, S., et al, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture”, RFC 3985, March 2005. [RFC3916] Xiao, X., et al, "Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [PW-MPLS] Martini, L., et al, "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-16.txt, March 2005, Work in progress. [PW-CW] Bryant, S., Swallow, G., McPherson, D., "PWE3 Control Word for use over an MPLS PSN", draft-ietf-pwe3-cw- 04.txt, June 2005, Work-in-progress. [FRAG] Malis, A., Townsley, M., "PWE3 Fragmentation and Reassembly", draft-ietf-pwe3-fragmentation-08.txt, February 2005, Work in Progress. [FC-BB] "Fibre Channel Backbone-3", T11/Project 1639-D/Rev 6.6, February 2005. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate requirement Levels", BCP 14, RFC 2119, March 1997. Roth, et al. Expires - December 2005 [Page 7] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 8. Informative references [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. [CEP] SONET/SDH Circuit Emulation Service Over Packet (CEP)",draft-ietf-pwe3-sonet-11.txt [Frame] "Frame Relay over Pseudo-Wires",draft-ietf-pwe3-frame- relay-05.txt [ATM] “Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks, draft-ietf-pwe3-atm-encap- 09.txt [ETH] Encapsulation Methods for Transport of Ethernet Over MPLS Networks, draft-ietf-pwe3-ethernet-encap-10.txt 9. Author's Addresses Moran Roth Corrigent Systems 126, Yigal Alon st. Tel Aviv, ISRAEL Phone: +972-3-6945433 Email: moranr@corrigent.com Ronen Solomon Corrigent Systems 126, Yigal Alon st. Tel Aviv, ISRAEL Phone: +972-3-6945316 Email: ronens@corrigent.com Munefumi Tsurusawa KDDI R&D Laboratories Inc. 2-1-15 Ohara, Kamifukuoka-shi Saitama, Japan Phone : +81-49-278-7828 10. Contributing Author Information David Zelig Corrigent Systems 126, Yigal Alon st. Tel Aviv, ISRAEL Phone: +972-3-6945273 Email: davidz@corrigent.com Roth, et al. Expires - December 2005 [Page 8] INTERNET DRAFT draft-roth-pwe3-fc-encap-00.txt June 2005 Leon Bruckman Corrigent Systems 126, Yigal Alon st. Tel Aviv, ISRAEL Phone: +972-3-6945694 Email: leonb@corrigent.com Luis Aguirre-Torres Corrigent Systems 101 Metro Drive Ste 680 San Jose, CA 95110 Phone: +1 408-392-9292 Email: Luis@corrigent.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Roth, et al. Expires - December 2005 [Page 9]