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]