One document matched: draft-ietf-pwe3-fc-encap-14.txt
Differences from draft-ietf-pwe3-fc-encap-13.txt
INTERNET-DRAFT David L. Black (ed.)
PWE3 WG EMC Corporation
Intended Status: Standard Track Linda Dunbar(ed.)
Expires: July 2011 Huawei Technologies
January 11, 2011
Encapsulation Methods for Transport of
Fibre Channel Traffic over MPLS Networks
draft-ietf-pwe3-fc-encap-14.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 July 11, 2011.
Copyright Notice
Copyright (c) 2011 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 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 Simplified BSD License.
Black and Dunbar Expires July 2011 [Page 1]
Internet-Draft FC Encapsulation January 2011
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
A Fibre Channel pseudowire (PW) is used to carry Fibre Channel
traffic over an MPLS network. This enables service providers to take
advantage of the reliable transport of MPLS-TE/MPLS-TP to offer
"emulated" Fibre Channel services. This document specifies the
encapsulation of Fibre Channel traffic 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].
Table of Contents
1. Introduction...................................................3
1.1. Transparency..............................................3
1.2. Bandwidth Efficiency......................................4
1.3. Reliability...............................................4
2. Reference Model................................................5
3. Encapsulation..................................................7
3.1. The Control Word..........................................8
3.2. MTU Requirements..........................................9
3.3. Mapping of FC traffic to PW packets.......................9
3.4. PW failure mapping.......................................12
4. Signaling of FC Pseudowires...................................12
5. Timing Considerations.........................................13
6. Security Considerations.......................................14
7. Applicability Statement.......................................15
8. IANA Considerations...........................................16
9. Acknowledgments...............................................17
Black and Dunbar Expires July 2011 [Page 2]
Internet-Draft FC Encapsulation January 2011
10. Normative References.........................................17
11. Informative references.......................................18
Authors' Addresses...............................................18
Contributors' Addresses..........................................18
1. Introduction
Fibre Channel (FC) is a high-speed communications technology, used
primarily for Storage Area Networks (SANs). Within a single site
(e.g., data center), an FC-based SAN connects servers to storage
systems, and FC can be extended across sites. When FC is extended
across multiple sites, the most common usage is storage replication
in support of recovery from disasters (e.g., flood or fire that takes
a site out of operation). This is particularly the case over longer
distances where network latency results in unacceptable performance
for a server whose storage is not at the same site. Fibre Channel is
standardized by INCITS Technical Committee T11 [T11] and multiple
methods for encapsulating and transporting FC traffic over other
networks have been developed [FC-BB-6].
FC/IP, as described in [RFC3821] and [FC-BB-6], 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 may not reliably deliver packets, FC/IP relies on the
TCP protocol to retransmit dropped frames. Due to possible delay
variation and TCP timeouts, special timing mechanisms are required to
ensure correct Fibre Channel operation over FC/IP [FC-BB-6].
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 traffic
over an MPLS network resulting in behavior similar to a pair of FC
ports that are directly connected by a physical FC link. The result
is simpler control processing by comparison to FC/IP.
This document specifies the encapsulation of FC traffic into an MPLS
pseudowire and related PW procedures to transport FC traffic over
MPLS PWs in conjunction with the specification of the FC portion of
the FC PW in [FC-BB-6]. The following subsections describe some of
the requirements for transporting FC traffic over an MPLS network.
1.1. Transparency
Transparent extension of an FC link is a key requirement for
transporting FC traffic over a PW. This requires the FC PW to emulate
Black and Dunbar Expires July 2011 [Page 3]
Internet-Draft FC Encapsulation January 2011
an FC Link between two FC ports, similar to the approach defined for
FC over GFPT in [FC-BB-6]. This results in transparent forwarding of
FC traffic over the MPLS network from both the FC Fabric and the
network operator points of view.
Transparency distinguishes the FC PW approach from FC/IP. An FC PW
logically connects the FC port on the FC link attached to one end of
the PW directly with the FC port on far end of the FC link attached
to the other end of the PW, whereas FC/IP introduces FC B_Ports at
both ends of the extended FC link; each FC B_Port is connected to an
FC E_Port in an FC switch on the same side of the link extension.
1.2. Bandwidth Efficiency
The bandwidth allocated to a PW may be less than the rate of the
attached FC port. When there is no data exchange on a native FC link,
Idle Primitive Signals are continuously exchanged between the two FC
ports. In order to improve the bandwidth efficiency across the MPLS
network, it is necessary for the FC PW PE to suppress (or drop) the
Idle Primitive signals generated by its adjacent FC ports. The far
end FC PW PE regenerates Idle Primitive signals to send to its
adjacent FC port as required, see [FC-BB-6].
FC link control protocols require an FC port to continuously send the
same FC Primitive Sequence [FC-FS-2] until a reply is received or
some other event occurs. To improve bandwidth efficiency, the FC PW
PE encapsulates a subset of repeated FC Primitive Sequences to send
across the WAN [FC-BB-6]. For example, in a sequence of identical
received primitives, only every fourth primitive may be sent across
the MPLS network. The far end FC PW PE regenerates the FC link
behavior by continuously sending the Primitive Sequence most recently
received from the WAN until a new primitive signal, primitive
sequence or data frame is received from the WAN.
These two bandwidth efficiency techniques may cause changes in the FC
traffic that traverses an FC PW (e.g., number of IDLE signals or
number of identical Primitive Sequences), but the far end FC PW PE's
regeneration of FC link behavior on the attached FC port is
transparent to the FC ports connected to each PW PE.
1.3. Reliability
Fibre Channel does not have a native retransmission protocol, and
requires reliable delivery of frames in the absence of errors. If an
FC frame cannot be delivered (e.g., is dropped or discarded as the
result of an error) the typical result is an I/O operation failure.
Recovery from that failure involves an I/O operation retry after what
Black and Dunbar Expires July 2011 [Page 4]
Internet-Draft FC Encapsulation January 2011
may be a significant delay (30 seconds and 60 seconds are typical
timeout values). In addition, such retries are likely to be logged
as errors indicating possible problems with FC equipment or cables.
Hence, drops, errors and discards of FC frames must be very rare.
In contrast to the TTL field in an IP packet, FC uses a constant
delivery timeout value (R_A_TOV) for which 10 seconds is the default.
Each FC frame must be delivered or discarded within that timeout
period after it is sent, see Section 5.
2. Reference Model
An FC PW extends a native FC link over an MPLS network. This document
specifies the PW encapsulation for FC. Figure 1 describes the
reference models (derived from [RFC3985]) that support the FC PW. FC
traffic is 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. This document
assumes that a pseudowire can be provisioned statically or via a
signaling protocol as defined in [RFC4447].
|<-------------- 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
Black and Dunbar Expires July 2011 [Page 5]
Internet-Draft FC Encapsulation January 2011
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 network
| | |y| | | |on | | | |y|
| C | +-+ +-----+ +------+ +------+ +-+
| E | | |
| | +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | MPLS | |P|
| |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To network
| | |y| | | |on | | | |y|
+---+ +-+ +-----+ +------+ +------+ +-+
| |
+-----------------------------------+
Figure 2: PW reference diagram
The Native Service Processing (NSP) function includes
o suppressing any FC Idle signals received from the PE's attached FC
port,
o re-generating FC Idle signals to send on the attached FC port when
there is no other FC traffic to send,
o selecting a subset of repetitive FC Primitive Sequences received
from the attached FC port and passing them to the PW Termination
Entity for encapsulation and forwarding to the PW tunnel (e.g.,
sending only every fourth, eighth or some other number of repeated
identical FC Primitive Sequences),
o re-sending the last received FC Primitive Sequence on the attached
FC port continuously until a new packet is received from the PW
WAN side, and
o using the Alternate Simple Flow Control (ASFC) protocol for buffer
management in concert with the peer PW PE's NSP function so that
FC traffic is not dropped. ASFC is a simple pause/resume protocol
that allows repetition of pause and resume operations; the
receiver responds to the first operation in an identical sequence
of operations, and ignores the rest of the sequence.
The NSP function is specified in detail by [FC-BB-6].
Black and Dunbar Expires July 2011 [Page 6]
Internet-Draft FC Encapsulation January 2011
3. Encapsulation
This specification provides port to port transport of FC encapsulated
traffic. There are several port types defined by Fibre Channel,
including:
o 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 a Node port.
o An NL_port is a port on the node used with an FC-AL topology. Also
known as a Node Loop port.
o 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 a Fabric
port. An F_port is not loop capable.
o 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.
o An E_port is a port used to connect two Fibre Channel switches.
Also known as an Expansion port. When E_ports between two switches
are connected to form a link, that link is referred to as an
inter-switch link (ISL).
Among the port types listed above, only the following FC connections
(as specified in [FC-BB-6]) are supported by an FC PW over MPLS:
- N_Port to N_Port, established by an FC PLOGI operation
- N_Port to F_Port, established by an FC FLOGI operation
- E_Port to E_Port, established by an FC ELP operation
FC traffic flowing over an FC PW is subdivided into four payload
types (PT) that are encoded in the PW Control Word (see Section 3.1):
1. FC login traffic (PT = 1): FC login operations and responses that
establish connections between FC ports. The three FC login
operations are PLOGI (Port Login), FLOGI (Fabric Login), and ELP
(Exchange Link Parameters). These operations and their responses
may require the NSP to allocate buffer resources, see the
specification of Login Exchange Monitors in [FC-BB-6].
2. FC data traffic (PT = 0): All FC frames other than those involved
in an FC login operation.
Black and Dunbar Expires July 2011 [Page 7]
Internet-Draft FC Encapsulation January 2011
3. FC Primitive Sequences and Signals (PT = 2): Native FC link
control operations - 4-character primitive sequences and signals
that are not encapsulated in FC frames. See [FC-BB-6] and
[FC-FS-2].
4. FC PW Control (PT = 6): FC PW control operations exchanged only
between the endpoints of the PW. FC PW control operations are used
for ASFC flow control, ping (e.g., for round trip latency
measurement) and reporting native FC link errors, see [FC-BB-6].
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 an 8b/10b transmission code (see [FC-FS-2]). The
protocol specified in this document converts a received 10b code to
its 8b counterpart for PW encapsulation, and hence does not support
attached FC links that use a 64b/66b transmission code (e.g., 10GFC,
16GFC); such links MUST NOT be attached to an FC PW PE. If an invalid
10b code that cannot be converted to an 8b code is received from an
FC link, the PE sends an FC PW control frame to report the error, see
[FC-BB-6].
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 bits 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
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 PT - Payload Type indication.
This field identifies the payload type carried by a PW packet. The
following types are defined:
Black and Dunbar Expires July 2011 [Page 8]
Internet-Draft FC Encapsulation January 2011
PT = 0: FC data frame.
PT = 1: FC login frame.
PT = 2: FC Primitive Sequence(s) and/or Primitive Signal(s).
PT = 6: FC PW Control Frame (refer to [FC-BB-6] 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, and
MUST be processed according to the rules specified 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.
3.2. MTU Requirements
The MPLS network MUST be able to transport the largest Fibre Channel
frame after encapsulation, including the overhead associated with the
encapsulation. The maximum FC frame size without PW and MPLS labels
(refer to Figure 4) is 2164 bytes. The MPLS network SHOULD
accommodate frames of up to 2500 bytes in order to support possible
future increases in the maximum FC frame size.
Fragmentation, described in [RFC4623], SHALL NOT be used for an FC
PW, therefore the network MUST be configured with a minimum MTU that
is sufficient to transport the largest encapsulated FC frame.
3.3. Mapping of FC traffic to PW packets
FC frames, Primitive Sequences, and Primitive Signals are transported
over the PW. All packet types are carried over a single PW. In
addition to the PW Control Word, an FC Encapsulation Header is
included in the PW packet. This FC Encapsulation Header is not used
in this version of the protocol; it SHOULD be set to zero by the
sender and MUST be ignored by the receiver.
Black and Dunbar Expires July 2011 [Page 9]
Internet-Draft FC Encapsulation January 2011
Each FC frame is mapped to a PW packet, 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
that 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 obtained directly from the FC attachment
channel, so that the PW PE is not required to re-calculate the CRC or
to check the CRC in the received frame. The CRC will be checked by
the FC port that receives the frame, ensuring that coverage is
provided for data errors that occur between the PW endpoints.
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 Frame ----+
| |
+---------------------------------------------------------------+
| CRC |
+---------------+-----------------------------------------------+
| EOF Code | Reserved |
+---------------+-----------------------------------------------+
Figure 4 - FC frame (SOF/Data/CRC/EOF) encapsulation in PW packet
FC Primitive Sequences and Primitive Signals are FC ordered sets. On
an 8b/10b-coded FC link, an ordered set consists of four 10b
characters, starting with the K28.5 character, followed by three
Dxx.y data characters. 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. A Kxx.y control character has a
different 10b code from the corresponding Dxx.y data character, but
uses the same 8b code (e.g., K28.5 and D28.5 both use the 8b code
0xBC). Here are two examples of ordered sets:
o Idle(IDLE) is K28.5 - D21.4 - D21.5 - D21.5. This FC primitive
signal is sent when the FC link is idle; it is suppressed by the
FC PW NSP and not sent over the WAN.
Black and Dunbar Expires July 2011 [Page 10]
Internet-Draft FC Encapsulation January 2011
o Link Reset Response(LRR) is K28.5 - D21.1 - D31.5 - D9.2 (this FC
primitive sequence is used as part of FC link initialization and
recovery).
Each ordered set is encapsulated in a PW packet containing the
encoded K28.5 control character [FC-BB-6], followed by three encoded
data characters, as shown in Figure 5.
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 in PW packet
The K28.5 10b control character received from the PE's attached FC
link is encoded for the FC PW as its 8b counterpart (0xBC). Because
the same 8b value is used to encode a D28.5 data word, the receiving
FC PW PE:
o MUST check for presence of an 8b K28.5 value (0xBC) at the start
of each ordered set (see Figure 5), and MUST send that value as a
10b K28.5 character on the attached FC link.
o MUST send the following three Dxx.y 8b values as Dxx.y 10b
characters on the attached FC link and MUST NOT send any of these
Dxx.y 8b values as 10b Kxx.y characters on the attached FC link.
A PW packet may contain one or more encoded FC Ordered sets [FC-BB-
6]. The length field in the FC PW Control Word is used to indicate
the packet length when the PW packet contains multiple Ordered Sets.
Idle Primitive Signals could be carried over the PW in the same
manner as Primitive Sequences. However, [FC-BB-6] requires that Idle
Primitive Signals be dropped by the Ingress PE and re-generated by
Black and Dunbar Expires July 2011 [Page 11]
Internet-Draft FC Encapsulation January 2011
the egress PE to save bandwidth consumed by FC (refer to [FC-BB-6]
for further details).
The egress PE extracts the Primitive Sequence or Primitive Signal
from the received PW packet. For a Primitive Sequence, the PE
continues transmitting the same FC Ordered Set to its attached FC
port until an FC frame or another ordered set is received over the
PW. A Primitive Signal is sent once, except that Idle Primitive
Signals are sent continuously when there is nothing else to send.
FC PW Control Frames are transported over the PW, by encapsulating
each frame in a PW packet with PT=6 in the Control Word. FC PW
Control Frame payloads are generated and terminated by the
corresponding FC entity. FC PW Control frames are used for FC PW flow
control (ASFC), ping and transmission of error indications. [FC-BB-6]
specifies the generation and processing of FC PW Control Frames.
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 PW Control Frame ----+
| |
+---------------------------------------------------------------+
Figure 6 - FC PW Control frame encapsulation in PW packet
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 attached FC link is
performed by the NSP, as defined by [FC-BB-6].
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.
Black and Dunbar Expires July 2011 [Page 12]
Internet-Draft FC Encapsulation January 2011
The PW Type field in the PWid FEC element and PW generalized ID FEC
elements MUST be set to the "FC Port Mode" value in section 7 below.
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 FC link
latency between CE1 and CE2 (refer to Figure 1) be:
o no more than one-half of the R_T_TOV (Receiver Transmitter Timeout
Value, default value: 100 milliseconds) of the attached devices
for Primitive Sequences;
o no more than one-half of the E_D_TOV (Error Detect Timeout Value,
default value: 2 seconds) of the attached devices for frames; and
o within the R_A_TOV (Resource Allocation Timeout Value, default
value: 10 seconds) of the attached fabric(s), if any. The FC
standards require that the E_D_TOV value for each FC link be set
so that the R_A_TOV value for the fabric is respected when the
worst case latency occurs for each link, see [FC-FS-2].
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.
These three timeout values are ordered (R_T_TOV < E_D_TOV < R_A_TOV),
so adherence to one-half of R_T_TOV for all FC PW traffic is
sufficient. See [FC-FS-2] for definitions of the FC timeout values.
The R_T_TOV is used by the FC link initialization protocol. If an FC
PW's latency exceeds one-half R_T_TOV, initialization of the FC link
that is encapsulated by the FC PW may fail, leaving that FC link in a
non-operational state.
The E_D_TOV is used to detect failures of operational FC links. If an
FC PW's latency exceeds the one-half E_D_TOV requirement, the FC link
Black and Dunbar Expires July 2011 [Page 13]
Internet-Draft FC Encapsulation January 2011
that is encapsulated by the FC PW may fail. The usual FC response to
such a link failure is to attempt to recover the FC link by
initializing it. That initialization will also fail if the FC PW
latency exceeds one-half R_T_TOV (a tighter requirement).
The R_A_TOV is used to determine when FC communication resources
(e.g., values that identify FC frames) may be reused. If an FC PW's
violation of the one-half E_D_TOV requirement is sufficient to also
cause the FC fabric to violate the R_A_TOV requirement, then FC reuse
of frame identification values after an R_A_TOV timeout may result in
multiple FC frames with the same identification values, causing
incorrect Fibre Channel operation. For example, if two such frames
are swapped between I/O operations, the result may be corrupted data
in the I/O operations.
The PING and PING_ACK FC PW control frames defined in Section 6.4.7
of [FC-BB-6] SHOULD be used to measure the current FC pseudowire
latency between the CE devices. If the measured latency violates any
of the timing requirements, then the FC PW PE MUST generate a WAN
Down event as specified in [FC-BB-6].
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
causes the FC link that is carried by the PW to become non-
operational, halting transmission of FC traffic. However, it is not
necessary to tear down the pseudowire itself in this situation (e.g.,
destroy the MPLS path set up by LDP).
The Transparent FC-BB initialization state machine in [FC-BB-6]
specifies the protocol used to attempt to recover from a 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 encapsulated 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 remains above 100ms, the initialization protocol
for the FC PW will repeatedly time out in attempting to recover from
the WAN Down event, preventing recovery of the FC link carried by the
PW, see [FC-BB-6].
6. Security Considerations
FC PW does not change the security properties of the underlying MPLS
network, rather it relies upon the network's mechanisms for
encryption, integrity, and authentication as required.
Black and Dunbar Expires July 2011 [Page 14]
Internet-Draft FC Encapsulation January 2011
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 FC traffic between Fibre
Channel ports while saving network bandwidth by removing FC Idle
Signals and reducing the number of FC Primitive Sequences.
o 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 FC links as specified by the FC standards.
o The FC PW carries only FC data frames, FC Primitive Signals and a
subset of the copies of an FC Primitive Sequence. Idle Primitive
Signals are suppressed, and long streams of the same Primitive
Sequence are reduced over the PW thus saving bandwidth.
o The PW PE MUST generate Idle Primitive Signals to the attached FC
link when there is no other traffic to transmit on the attached FC
link [FC-FS-2].
o The PW PE MUST send Primitive Sequences continuously to the
attached FC port, as required by the FC standards [FC-FS-2].
FC PW traffic should only traverse controlled MPLS or MPLS-TP
networks. The network should enforce policing of incoming traffic and
network resource/bandwidth allocation so that the FC PW delivery
quality can be assured. To extend FC across an uncontrolled network,
FC/IP SHOULD be used instead of an FC PW, see [RFC3821] and
[FC-BB-6].
This document does not provide any mechanisms for protecting an FC PW
against network outages. As a consequence, resilience of the emulated
FC service to such outages is dependent upon MPLS-TE/MPLS-TP network.
The NSP SHOULD use a WAN Down event (as specified in [FC-BB-6]) to
convey the PW status to the CE, to enable faster network outage
handling.
Black and Dunbar Expires July 2011 [Page 15]
Internet-Draft FC Encapsulation January 2011
8. IANA Considerations
IANA is requested to assign a new MPLS Pseudowire (PW) type as
follows:
PW type Description Reference
-------- -------------- ----------
0x001F FC Port Mode RFC XXXX
The above value is suggested as the next available value and has been
reserved for this purpose by IANA.
RFC Editor: Please replace RFC XXXX above with the RFC number of this
document and remove this note.
IANA should reserve the following Pseudowire Interface Parameters
Sub-TLV Types that were tentatively allocated for FC PW and restrict
them to prevent future allocation. These Sub-TLV types were used for
the FC PW Selective Retransmission protocol, which the working group
has decided to eliminate. This action prevents future use of these
values for other purposes, just in case there are implementations of
the Selective Retransmission protocol.
Parameter ID Length Reference
--------- --------- ----------
0x12 4 RFC XXXX
0x13 4 RFC XXXX
0x14 4 RFC XXXX
0x15 4 RFC XXXX
RFC Editor: Please replace RFC XXXX above with the RFC number of this
document and remove this note.
Black and Dunbar Expires July 2011 [Page 16]
Internet-Draft FC Encapsulation January 2011
9. Acknowledgments
Previous versions of this document were authored by Moran Roth, Ronen
Solomon and Munefumi Tsurusawa (see Contributors' Addresses, below);
their efforts and contributions are gratefully acknowledged. The
authors would like to thank Stewart Bryant, Dave Peterson, Yaakov
Stein and Alexander Vainshtein for helpful comments on this document.
The protocol specified in this document is intended to be used in
conjunction with the Fibre Channel pseudowire portion of the FC-BB-6
specification developed by INCITS Technical Committee T11. The
authors would like to thank the members of both IETF and T11
organizations who have supported and contributed to this work.
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.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", RFC 4446, 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-6] "Fibre Channel Backbone-6" (FC-BB-6), T11 Project
2159-D, Rev 1.02, October 2010.
[RFC-2119] 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.
Black and Dunbar Expires July 2011 [Page 17]
Internet-Draft FC Encapsulation January 2011
[FC-SP] "Fibre Channel - Security Protocols" (FC-SP), ANSI
INCITS 426:2007, February 2007.
11. Informative references
[RFC3821] M. Rajogopal, E. Rodriguez, "Fibre Channel over TCP/IP
(FCIP)", RFC 3821, July 2004.
[T11] INCITS Technical Committee T11, http://www.t11.org,
visited January, 2011.
Authors' Addresses
David L. Black (ed.)
EMC Corporation
176 South Street
Hopkinton, MA 01748
Phone: +1 (508) 293-7953
Email: david.black@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
Contributors' Addresses
Moran Roth
Infinera Corporation
169 Java Drive
Sunnyvale, CA 94089
Phone: (408) 572-5200
Email: MRoth@infinera.com
Ronen Solomon
Orckit-Corrigent Systems
126, Yigal Alon st.
Tel Aviv, ISRAEL
Phone: +972-3-6945316
Email: ronens@corrigent.com
Black and Dunbar Expires July 2011 [Page 18]
Internet-Draft FC Encapsulation January 2011
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 July 2011 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 09:55:46 |