PWE3 David L. Black (ed.)
Internet-Draft EMC Corporation
Intended status: Standard Track Linda Dunbar(ed.)
Expires: August 2010 Huawei Technologies
Moran Roth
Ronen Solomon
Corrigent Systems
Munefumi Tsurusawa
KDDI
February 25, 2010
Encapsulation Methods for Transport of Fibre Channel frames Over MPLS
Networks
draft-ietf-pwe3-fc-encap-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
This Internet-Draft will expire on August 25, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Black and Dunbar Expires August 25, 2010 [Page 1]
Internet-Draft FC Encapsulation February 2010
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract
A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames
over an MPLS network. This enables service providers to take full
advantage of the reliable transport of MPLS-TE/MPLS-TP to offer
"emulated" Fibre Channel services. This document specifies the
encapsulation of Fibre Channel PDUs within a pseudowire. It also
specifies the common procedures for using a PW to provide a Fibre
Channel service. The mechanisms controlling the reliable transport of
Fibre Channel PW over MPLS networks can be provided by MPLS-TP.
Conventions used in this document
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 0.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.1. Transparency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.2. Bandwidth Efficiency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
2. Reference Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
3. Encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
3.1. The Control Word. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
3.2. MTU Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
3.3. Mapping of FC traffic to PW PDU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
3.4. PW failure mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Signaling of FC Pseudowires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Timing Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Applicability Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative references. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Black and Dunbar Expires August 25, 2010 [Page 2]
Internet-Draft FC Encapsulation February 2010
1. Introduction
Fibre Channel Storage Area Networks (SAN) extension for disaster
recovery has become an important potential source of network traffic.
In order to meet Fibre Channel's network service requirements, such
as transparency and low latency, multiple methods for encapsulating
and transporting FC frames over backbone networks have been developed
[FC-BB].
FC/IP, as described in [RFC3821] and [FC-BB], interconnects otherwise
isolated FC SANs over IP Networks. FC/IP uses FC Frame Encapsulation,
[RFC3643] to encapsulate FC frames and addresses concerns specific to
tunneling FC over an IP-based network. Since such networks do not
reliably deliver packets, FC/IP relies on the TCP protocol to
retransmit dropped frames. Due to possible delay variation and TCP
re-transmission timeouts, special timing mechanisms are required to
ensure correct Fibre Channel operation over FC/IP [FC-BB].
MPLS-TP and MPLS-TE provide mechanisms for reliable transport over
MPLS networks, making it possible for Fibre Channel ports to be
interconnected directly over MPLS networks. A Fibre Channel
pseudowire (FC PW) is a method to transparently transport FC frames
over an MPLS network resulting in behavior similar to that of two FC
ports are directly connected by a physical link. The result is
considerably simpler control processing at both Ingress and Egress by
comparison to FC/IP.
This document defines the encapsulation of FC Protocol Data Units
(PDU) into an MPLS pseudowire and related procedures for using PW
encapsulation. The following sections describe some of the key
requirements for transporting FC frames over an MPLS PSN.
1.1. Transparency
Transparent emulation of an FC link is a key requirement for
transporting FC frames over a carrier's network. This requires the FC
PW to emulate an FC Link between two FC ports, similar to the
approach defined for FC over GFPT in [FC-BB]. This results in
transparent forwarding of FC frames over the MPLS PSN from both the
FC Fabric and the operator's points of view.
Transparency distinguishes the FC PW approach from FC/IP. An FC PW
logically connects the FC port on one end of PW directly with the FC
port on the other end of PW, whereas FC/IP introduces FC B_Ports at
both ends of the extended FC link; each FC B_Port is logically
connected to the FC port on the same side of the link extension.
Black and Dunbar Expires August 25, 2010 [Page 3]
Internet-Draft FC Encapsulation February 2010
1.2. Bandwidth Efficiency
The bandwidth allocated to PW can be less than the rate of the
attached FC port. When there is no data exchange between the two
directly connected FC ports, Idle Primitive signals are continuously
exchanged between the two FC ports to keep the FC Link up. In order
to improve the bandwidth efficiency across the MPLS network, it is
necessary for PW PE to suppress (or drop) the Idle Primitive signals
generated by its adjacent FC ports. The far end PW PE regenerates
Idle Primitive signals to send to its adjacent FC port as necessary,
see [FC-BB].
FC link protocols may send the same FC Primitive Sequence [FC-FS-2]
between two directly connected FC ports until a reply is received. To
improve bandwidth efficiency, the PW PE only encapsulates a subset of
the received repetitive FC Primitive Sequences to send across the PW
tunnel [FC-BB]. E.g., one out of each set of four identical received
primitives is sent across the MPLS network. The far end PW PE has to
send the Primitive Sequences received from the WAN side, i.e. from PW
tunnel, to its attached FC port continuously until a new primitive
sequence or data frame is received from the WAN.
Another requirement for transporting FC over an MPLS PSN is to
minimize the protocol overhead to optimize the bandwidth consumed by
the FC traffic. FC PW has an overhead of 16 bytes, consisting of the
FC Encapsulation Header (4 bytes), the Control Word (4 bytes), the PW
label (4 bytes) and the MPLS label (4 bytes).
2. Reference Model
FC 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 can be
provisioned statically or through signaling protocol as defined in
[RFC4447].
FC PW emulates a single FC link between exactly two endpoints. This
document specifies the emulated PW encapsulation for FC. Figure 1
describes the reference models which are derived from [RFC3985] to
support the FC PW emulated services. FC PDUs are received by PE1's FC
attachment channel, encapsulated at PE1, transported across MPLS
network, decapsulated at PE2, and transmitted onward via the PE2's FC
attachment channel.
Black and Dunbar Expires August 25, 2010 [Page 4]
Internet-Draft FC Encapsulation February 2010
|<-------------- Emulated Service ----------------->|
| |
| |<------- Pseudowire -------->| |
| | | |
| | |<-- MPLS 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
The following reference model describes the termination point of each
end of the PW within the PE:
+-----------------------------------+
| PE |
+---+ +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | MPLS | |P|
| |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
| | |y| | | |on | | | |y|
| C | +-+ +-----+ +------+ +------+ +-+
| E | | |
| | +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | MPLS | |P|
| |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
| | |y| | | |on | | | |y|
+---+ +-+ +-----+ +------+ +------+ +-+
| |
+-----------------------------------+
Figure 2: PW reference diagram
Black and Dunbar Expires August 25, 2010 [Page 5]
Internet-Draft FC Encapsulation February 2010
The Native Service Processing (NSP) function includes
- suppressing the FC Idle frames received from the PE's attached
FC port,
- re-generating the Idle frames and send to its attached FC port
when there is no FC data frames are received from PW WAN side,
- selecting a subset of repetitive FC Primitive Sequences
received from its attached FC port and passing them to the PW
Termination Entity for both encapsulation and forwarding to the
PW tunnel, and
- sending the received FC Primitive Sequence received from the PW
tunnel to PE's attachment FC port continuously until a new
frame is received from PW tunnel.
The NSP function is specified in detail by [FC-BB].
3. Encapsulation
This specification provides port to port transport of FC encapsulated
traffic. There are several port types defined by Fibre Channel,
including:
An N_port is a port on the node (e.g. host or storage device)
used with both FC-P2P or FC-SW topologies. Also known as Node
port.
An NL_port is a port on the node used with an FC-AL topology.
Also known as Node Loop port.
An F_port is a port on the switch that connects to a node point-
to-point (i.e. connects to an N_port). Also known as Fabric
port. An F_port is not loop capable.
An FL_port is a port on the switch that connects to a FC-AL loop
(i.e. to NL_ports). Also known as Fabric Loop port.
E_port is the connection between two fibre channel switches.
Also known as an Expansion port. When E_ports between two
switches form a link, that link is referred to as an inter-
switch link (ISL).
Black and Dunbar Expires August 25, 2010 [Page 6]
Internet-Draft FC Encapsulation February 2010
Among the port types listed above, only the following FC connections
(as specified in [FC-BB]) are supported by an FC PW over MPLS:
- 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].
This FC PW specification is limited to use with FC service classes 2,
3 and F (see [FC-FS-2]). Other FC service classes (e.g., 1, 4 and 6)
MUST NOT be used with an FC PW. This FC PW specification is limited
to native FC attachment links that employ the 8b/10b transmission
code used by FC (see [FC-FS-2]). The protocol specified in this
document is not sufficient to support attached FC links that use a
64b/66b transmission code (e.g., 10GFC); such links MUST NOT be
attached to an FC PW.
3.1. The Control Word
The Generic PW Control Word, as defined in "PWE3 Control Word"
[RFC4385] MUST be used for FC PW to facilitate the transport of short
packets (by setting the Length field as detailed below), and convey
the flag bit defined below. The structure of the Control Word is as
follows:
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| PT |X|0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Control Word structure for the one-to-one mapping mode
The first four bits of the PW Control Word MUST be set to 0 by the
ingress PE to indicate PW data.
The Flags bits are in use to convey the value of two flags, as
specified below.
Black and Dunbar Expires August 25, 2010 [Page 7]
Internet-Draft FC Encapsulation February 2010
PT - Payload Type indication. This field identifies the payload type
carried within the PW PDU. The following types are defined:
PT = 0: FC data frame.
PT = 1: FC login frame.
PT = 2: FC Primitive Sequence.
PT = 6: FC Control Frame (refer to [FC-BB] for usage).
X - This bit is not used by this version of the protocol. It SHOULD
be set to zero by the sender and MUST be ignored by the receiver.
The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
These bits may be used in the future for FC specific indications as
defined in [RFC4385].
The length field MUST be used for packets shorter than 64 bytes. Its
processing must follow the rules defined in [RFC4385].
The sequence number is not used for FC PW and MUST be set to 0 by the
ingress PE, and MUST be ignored by the egress PE. Refer to section 6
for the sequencing mechanism used for FC PW.
3.2. MTU Requirements
The MPLS PSN MUST be able to transport the largest Fibre Channel
encapsulation frame, including the overhead associated with the
tunneling protocol. The maximum frame size without PW and MPLS labels
(refer to Figure 4) is 2164 bytes. The MPLS PSN SHOULD accommodate
frames of up to 2500 bytes to support future expansion of FC frames.
Fragmentation, described in [RFC4623], SHALL NOT be used for FC PW,
therefore the network MUST be configured with a minimum MTU that is
sufficient to transport the largest encapsulation frame.
3.3. Mapping of FC traffic to PW PDU
FC frames and Primitive Sequences are transported over the PW. All
packet types are carried over a single PW. In addition to the PW
Control Word, a FC Encapsulation Header has to be included in the
frame. The FC Encapsulation Header is not used in this version of the
protocol. This field SHOULD be set to zero by the sender and MUST be
ignored by the receiver.
Black and Dunbar Expires August 25, 2010 [Page 8]
Internet-Draft FC Encapsulation February 2010
Each FC frame is mapped to a PW PDU, including the Start Of Frame
(SOF) delimiter, frame header, CRC field and the End Of Frame (EOF)
delimiter, as shown in figure 4. The SOF and EOF frame delimiters are
each encoded into a single byte as specified in [RFC3643], except the
codes for delimiters that apply only to FC service class 4 (SOFi4,
SOFc4, SOFn4, EOFdt, EOFdti, EOFrt, EOFrti) MUST NOT be used. The CRC
in the frame is directly from FC attachment channel, so the PW PE is
not required to re-calculate the CRC or to check the CRC in the
received frame either.
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
+---------------------------------------------------------------+
| FC PW Control Word |
+---------------------------------------------------------------+
| FC Encapsulation Header |
+---------------+-----------------------------------------------+
| SOF Code | Reserved |
+---------------+-----------------------------------------------+
| |
+----- FC Data Frame ----+
| |
+---------------------------------------------------------------+
| CRC |
+---------------+-----------------------------------------------+
| EOF Code | Reserved |
+---------------+-----------------------------------------------+
Figure 4 - FC frame (SOF/EOF/CRC/Data) encapsulation within PW PDU
FC Primitive Sequences and Primitive Signals are encapsulated in a PW
PDU containing the encoded K28.5 character [FC-BB], followed by the
encoded 3 data characters, as shown in Figure 5. Each K28.5 - Dxx.y -
Dxx.y - Dxx.y set of 4 octets represents an FC ordered set, which is
either a primitive signal or a primitive sequence for the FC PW. All
FC ordered sets start with a K28.5 control character, but the three
following Dxx.y data characters differ depending on the ordered set.
Here are a couple of ordered set examples:
- Receiver Ready (R_RDY) is K28.5 - D21.4 - D10.2 - D10.2 (this FC
primitive signal is used for FC link flow control).
- Link Reset Response(LRR) is K28.5 - D21.1 - D31.5 - D9.2 (this FC
primitive sequence is used by FC link initialization and recovery
protocols).
Black and Dunbar Expires August 25, 2010 [Page 9]
Internet-Draft FC Encapsulation February 2010
The K28.5 10b control character received from the attached FC link is
encoded for the FC PW as its 8b counterpart (0xBC). The 8b encoding
is also used to encode a D28.5 data word; the receiving PW PE MUST
check for presence of an 8b K28.5 value (0xBC) at the start of each
ordered set (see Figure 5), MUST send that value as a 10b K28.5
character on the attached FC link, and MUST send the following 3
Dxx.y 8b values as Dxx.y 10b characters on the attached FC link
(i.e., Must not send the 3 Dxx.y 8b values as the 10b Kxx.y
characters on the attached FC link).
A PW PDU may contain one or more encoded FC Ordered sets [FC-BB]. The
length field in the FC PW Control Word is used to indicate the packet
length when the PW PDU contains multiple Ordered Sets.
Idle Primitive Signals can be carried over the PW in the same manner
as Primitive Sequences. However, [FC-BB] requires that Idle Primitive
Signals be dropped by the Ingress PE and re-generated by the egress
PE to save bandwidth consumed by FC (refer to [FC-BB] for further
details).
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
+---------------------------------------------------------------+
| FC PW Control Word |
+---------------------------------------------------------------+
| FC Encapsulation Header |
+---------------+---------------+---------------+---------------+
| 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
The egress PE extracts the Primitive Sequence or Primitive Signal
from the received PW PDU. For a Primitive Sequence, the PE continues
transmitting the same FC Ordered Set to its attachment FC port until
a FC frame or another ordered set is received over the PW. A
Black and Dunbar Expires August 25, 2010 [Page 10]
Internet-Draft FC Encapsulation February 2010
Primitive Signal is sent once, except that Idle Primitive Signals are
sent continuously when there is nothing else to send.
FC Control frames are transported over the PW, by encapsulating each
frame in a PW PDU. FC PW Control Word must have PT = 6. FC Control
Frame payload is generated and terminated by the corresponding FC
entity. How the FC Control Frame is generated and processed are
defined in [FC-BB].
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
+---------------------------------------------------------------+
| FC PW Control Word |
+---------------------------------------------------------------+
| FC Encapsulation Header |
+---------------------------------------------------------------+
| |
+----- FC Control Frame ----+
| |
+---------------------------------------------------------------+
Figure 6 - FC Control frame encapsulation within PW PDU
3.4. PW failure mapping
PW failure mapping, which are detected through PW signaling failure,
PW status notifications as defined in [RFC4447], or through PW OAM
mechanisms MUST be mapped to emulated signal failure indications.
Sending the FC link failure indication to its attachment FC channel
is performed by the NSP, as defined by [FC-BB], and is out of the
scope of this document.
4. Signaling of FC Pseudowires
RFC4447 specifies the use of the MPLS Label Distribution Protocol,
LDP, as a protocol for setting up and maintaining pseudowires. This
section describes the use of specific fields and error codes used to
control FC PW.
The PW Type field in the PWid FEC element and PW generalized ID FEC
elements MUST be set to "FC Port Mode" as requested in section 7
below.
Black and Dunbar Expires August 25, 2010 [Page 11]
Internet-Draft FC Encapsulation February 2010
The Control Word is REQUIRED for FC pseudowires. Therefore the C-Bit
in the PWid FEC element and PW generalized ID FEC elements MUST be
set. If the C-Bit is not set the pseudowire MUST not be established
and a Label Release MUST be sent with an "Illegal C-Bit" status code
[RFC4447].
The Fragmentation Indicator (Parameter ID = 0x09) is specified in
[RFC4446] and its usage is defined in [RFC4623]. Since fragmentation
is not used in FC PW, the fragmentation indicator parameter MUST be
omitted from the Interface Parameter Sub-TLV.
5. Timing Considerations
Correct Fibre Channel link operation requires that the latency
between CE1 and CE2 (refer to Figure 1) be:
a) no more than one-half of the R_T_TOV (Receiver Transmitter
Timeout Value, default value: 100 milliseconds, defined in [FC-FS])
of the attached devices for Primitive Sequences;
b) no more than one-half of the E_D_TOV (Error Detect Timeout
Value, default value: 2 seconds, defined in [FC-FS]) of the attached
devices for frames; and
c) within the R_A_TOV (Resource Allocation Timeout Value, default
value: 10 seconds, defined in [FC-FS]) of the attached fabric(s), if
any.
An FC PW MUST adhere to these three timing requirements and MUST NOT
be used in environments where high or variable latency may cause
these requirements to be violated.
Failure to adhere to requirement a) may result in FC link failures
(e.g., FC link initialization protocol times out). Failure to adhere
to requirements b) and c) may cause incorrect Fibre Channel
operation, including possible corruption of stored data when Fibre
Channel is used to access storage systems.
The PING and PING_ACK signals defined in Section 6.4.7 of [FC-BB] MAY
be used to measure the current FC pseudowire latency between the CE
devices.
If the measured latency violates any of the above 3 requirements, the
FC PW PE MUST generate a WAN Down event as specified in [FC-BB]. The
WAN Down event causes the PE to continuously send NOS (an FC
primitive sequence) on the native FC link to the attached FC Port
(typically an E_Port on a switch in this case). This immediately
Black and Dunbar Expires August 25, 2010 [Page 12]
Internet-Draft FC Encapsulation February 2010
causes the FC link that is carried by the PW to be taken down,
halting transmission of FC traffic. However, it is not necessary to
tear down the pseudowire itself (i.e., destroy the MPLS path set up
by LDP). The state machine in Section 6.4.2 of [FC-BB] specifies the
protocol used to attempt to recover from the WAN Down event (i.e.,
bring the WAN back up). If that protocol brings the WAN back up, FC
traffic will resume and the standard FC link recovery protocol will
bring the carried FC link back up. If the previous pseudowire was
destroyed, attempts will be made to re-establish the path via LDP as
part of recovering from the WAN Down event.
If the PW round-trip latency stays above 100ms, the initialization
protocol for the FC PW will repeatedly time out in attempting to
recover from the WAN Down event, preventing FC recovery of the FC
link carried by the PW.
6. Security Considerations
FC PW does not change the security properties of the underlying MPLS
PSN, rather it relies upon the PSN's mechanisms for encryption,
integrity, and authentication as required.
FC PW shares susceptibility to a number of pseudowire-layer attacks
and implementations SHOULD use whatever mechanisms for
confidentiality, integrity, and authentication are developed for PWs
in general. These methods are beyond the scope of this document.
The protocols used to implement security in a Fibre Channel fabric
are defined in [FC-SP]. These protocols operate at higher layers of
the FC hierarchy and are transparent to the FC PW.
7. Applicability Statement
FC PW allows the transparent transport of point-to-point Fibre
Channel ports while saving network bandwidth by removing or reducing
the FC Idle Signals and Primitive Sequences.
- The pair of CE devices operates as if they were directly connected
by an FC link. In particular they react to Primitive Sequences on
their local ACs in the standard way.
- The FC PW carries only FC data frames and a single copy of a
Primitive Sequence. Idle Primitive Signals encountered between FC
data frames, and long streams of the same Primitive Sequence are
suppressed over the PW thus saving bandwidth.
Black and Dunbar Expires August 25, 2010 [Page 13]
Internet-Draft FC Encapsulation February 2010
- The PW PE MUST generate Idle Primitive Signals to the FC attachment
channel when there is no frame transmitted across the MPLS network.
FC PW traffic should only traverse through controlled MPLS or MPLS-TP
networks. The network should enforce proper policing of incoming
traffic and proper network resource/bandwidth allocation so that the
FC PW delivery quality can be guaranteed. To extend FC across an
uncontrolled network, FC/IP SHOULD be used instead of an FC PW.
This document does not provide any mechanisms for protecting FC PW
against PSN outages. As a consequence, resilience of the emulated
service to such outages is dependent upon MPLS-TE/MPLS-TP network.
However, the NSP MAY implement a mechanism to convey the PW status to
the CE, to enable faster handling of the PSN outage.
8. IANA Considerations
IANA is requested to assign a new PW type as follows:
PW type Description Reference
-------- -------------- ----------
0x001F FC Port Mode [FC-encap]
The above value is suggested as the next available value.
[Editor's Note - is this necessary?] IANA should reserve the
following Sub-TLV types which were tentatively allocated for FC PW.
These Sub-TLV types were used for an FC PW Selective Retransmission
protocol for FC PW, that the working group has decided to eliminate.
This reservation action prevents future use of these values for other
purposes, just in case there are implementations of the Selective
Retransmission protocol.
Parameter ID Length
--------- ---------
0x12 4
0x13 4
0x14 4
0x15 4
Black and Dunbar Expires August 25, 2010 [Page 14]
Internet-Draft FC Encapsulation February 2010
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
10. Normative References
[RFC3643] Weber, R., et al, "Fibre Channel (FC) Frame
Encapsulation", RFC 3643, December 2003.
[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.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", RFC 4447, April 2006.
[RFC4447] Martini, L., et al, "Pseudowire Setup and Maintenance
using the Label Distribution Protocol (LDP)", RFC4447,
April 2006.
[RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-
Edge(PWE3) Control Word for use over an MPLS PSN",
RFC4385, February 2006.
[RFC4623] Malis, A., Townsley, M., "PWE3 Fragmentation and
Reassembly", RFC 4623, August 2006.
[FC-BB] "Fibre Channel Backbone-4" (FC-BB-4), ANSI INCITS
419:2008, August 2008. [Editor's Note: will change
this reference to FC-BB-6 in a future draft version.]
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
requirement Levels", BCP 14, RFC 2119, March 1997.
[FC-FS-2] "Fibre Channel - Framing and Signaling-2 (FC-FS-2)",
ANSI INCITS 424:2007, August 2007.
[FC-SP] "Fibre Channel - Security Protocols" (FC-SP), ANSI
INCITS 426:2007, February 2007.
Black and Dunbar Expires August 25, 2010 [Page 15]
Internet-Draft FC Encapsulation February 2010
11. Informative references
[RFC3821] M. Rajogopal, E. Rodriguez, "Fibre Channel over TCP/IP
(FCIP)", RFC 3821, July 2004.
[RFC4448] Martini, L., et al, "Encapsulation Methods for
Transport of Ethernet over MPLS Networks", RFC 4448,
April 2006.
[RFC4842] Malis, A., et al, "SONET/SDH Circuit Emulation Over
Packet (CEP)", RFC 4842, April 2007.
[RFC4619] Martini, L., et al, "Encapsulation Methods for
Transport of Frame Relay over MPLS Networks", RFC
4619, September 2006.
[RFC4717] Martini, L., et al, "Encapsulation Methods for
Transport of ATM over MPLS Networks", RFC 4717,
December 2006.
Authors' Addresses
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
Phone: +1 (508) 293-7953
Email: black_david@emc.com
Linda Dunbar (Ed.)
Huawei Technologies
1700 Alma Drive, Suite 500
Plano, TX 75075, USA
Phone: +1 (972) 543-5849
Email: ldunbar@huawei.com
Moran Roth
Corrigent Systems
101, Metro Drive
San Jose, CA 95110
Phone: +1-408-392-9292
Email: moranr@corrigent.com
Ronen Solomon
Corrigent Systems
126, Yigal Alon st.
Tel Aviv, ISRAEL
Black and Dunbar Expires August 25, 2010 [Page 16]
Internet-Draft FC Encapsulation February 2010
Phone: +972-3-6945316
Email: ronens@corrigent.com
Munefumi Tsurusawa
KDDI R&D Laboratories Inc.
Ohara 2-1-15, Fujimino-shi,
Saitama, Japan
Phone: +81-49-278-7828
Intellectual Property Statement
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Black and Dunbar Expires August 25, 2010 [Page 17]
Internet-Draft FC Encapsulation February 2010
Black and Dunbar Expires August 25, 2010 [Page 18]
