One document matched: draft-ietf-pwe3-fc-encap-01.txt
Differences from draft-ietf-pwe3-fc-encap-00.txt
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
PWE3
Internet Draft Moran Roth (Ed.)
Document: draft-ietf-pwe3-fc-encap-01.txt Ronen Solomon
Expires: December 2006 Corrigent Systems
Munefumi Tsurusawa
KDDI
June 2006
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.
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.
Roth, et al. Expires - December 2006 [Page 1]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
Table of Contents
1. Specification of Requirements..................................2
2. Introduction...................................................2
2.1. Transparency..............................................4
2.2. Bandwidth Efficiency......................................4
2.3. Traffic Engineering.......................................4
2.4. Security..................................................5
3. Reference Model................................................5
4. Encapsulation..................................................7
4.1. The Control Word..........................................7
4.1.1. Setting the sequence number.............................7
4.1.2. Processing the sequence number..........................8
4.2. MTU Requirements..........................................8
4.3. Mapping of FC traffic to PW PDU...........................9
4.4. PW failure mapping.......................................10
5. Signaling of FC Pseudo Wires..................................10
6. Congestion Control............................................11
6.1. Rate Control.............................................11
6.1.1. Protocol Mechanism.....................................11
6.1.2. Data Sender Protocol...................................12
6.1.3. Data Receiver Protocol.................................13
6.2. Selective Retransmission.................................14
7. Security Considerations.......................................14
8. Applicability Statement.......................................14
9. IANA considerations...........................................15
10. References...................................................15
11. Informative references.......................................16
12. Author's Addresses...........................................16
13. Contributing Author Information..............................17
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. Introduction
As metro transport networks migrate towards a packet-oriented
transport infrastructure, the PSN is being extended in order to allow
all services to be transported over a common network infrastructure.
This has been accomplished for services such as Ethernet [RFC4448],
Frame Relay [FRAME], ATM [ATM] and SONET/SDH [CEP] services. Another
such service, which has yet to be addressed, is the transport of
Roth, et al. Expires - December 2006 [Page 2]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
Fibre Channel frames over the PSN. This will allow network service
providers to transparently carry Fibre Channel services over the
packet-oriented transport network, along with the aforementioned data
and TDM services.
During recent years applications such as SAN extension and disaster
recovery have become a prominent business opportunity for network
service providers. In order to meet the intrinsic service
requirements that characterize FC-based applications, such as
transparency and low latency, various methods for encapsulating and
transporting FC frames over a PSN have been developed. One such
method is FC over MPLS (FC/MPLS), which provides an alternative to
FC/IP, as well as to the various interconnect technologies described
as part of [FC-BB].
This section focuses on the applicability of methods and procedures
to encapsulate FC over MPLS, specifically those which are relevant to
the IETF. It concentrates particularly on the methods defined by the
IETF PWE3 WG for the encapsulation of service frames and emulation
using MPLS pseudo-wires (PW). This section, however, does not attempt
to define the relationship between FC and MPLS as transport
technology, as this method was only recently approved as an FC-BB-4
working item, and is under consideration in Technical committee T11.
FC/MPLS provides a method for transporting FC frames over an MPLS-
based transport network, such as a packet-oriented transport network,
in this document also referred to simply as PSN. It defines the
encapsulation of FC PDUs into an MPLS pseudo-wire (PW), as well as
procedures for using PW encapsulation to enable FC services such as
SAN extension and disaster recovery over a PSN. FC/IP, as described
in [RFC3821], defines the mechanisms that allow the interconnection
of islands of FC SANs over IP Networks. It provides a method for
encapsulating FC frames employing FC Frame Encapsulation, as defined
in [RFC3643], and addresses specific FC concerns related to tunneling
FC over an IP-based network.
FC/MPLS is being proposed to complement the currently available
standardized methods for transporting FC frames over a PSN.
Specifically, FC/IP addresses “only the requirements necessary to
properly utilize an IP network as a conduit for FC Frames”, whereas
FC/MPLS addresses the requirements necessary to transport FC over an
MPLS-based PSN. An example of such a network might be a L2 PSN or a
packet-oriented multi-service transport network, where MPLS is used
as the universal method for encapsulating and transporting all type
of services, including mission critical FC applications as well as
other TDM and data services. Hence, a key benefit of FC/MPLS is that
it will enable the extension of FC applications to the carrier
transport space.
Roth, et al. Expires - December 2006 [Page 3]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
The following sections describe some of the key carrier requirements
for transporting FC frames over an MPLS-based PSN.
2.1. Transparency
Transparent emulation of an FC link is a key requirement for
transporting FC frames over a carrier’s transport network.
Conventionally, the coupling (or pairing) of FC entities with those
pertaining to specific encapsulation methods requires the protocol-
specific entity to terminate the FC Entity. This, in most cases,
would require global address synchronization to be performed by the
operator. In addressing this requirement, and providing full
transparency, FC/MPLS defines a port-mode FC encapsulation into an
MPLS PW. This requires the creation of an FC pseudo-wire emulating an
FC Link between two FC ports, appearing architecturally as being
wired to those ports, similar to the approach defined for FC over
GFPT in [FC-BB]. This results in transparent forwarding of FC frames
over the MPLS-based PSN from both the FC Fabric and the operator’s
point of view.
2.2. Bandwidth Efficiency
This is an important requirement for transporting FC over an MPLS-
based PSN, where the protocol overhead has to be minimized in order
to guarantee an end-to-end performance consistent with, e.g., SONET
transport networks. FC/MPLS defines a minimal overhead of 20 bytes,
required due to the inclusion of the FC-BB header (8 bytes), as well
as the control word (4 bytes), PW label (4 bytes) and MPLS label (4
bytes). This can be contrasted with the overhead required by other
methods such as those defined in [FC-BB].
Moreover, the ability to characterize services by specific bandwidth
attributes, such as Committed Information Rate (CIR) and Excess
Information Rate (EIR), effectively enables network operators to take
full advantage of the statistical multiplexing capabilities of a
packet-oriented transport network. This allows the multiplexing of
best effort and premium services over the same media, effectively
optimizing bandwidth utilization while still providing bandwidth
guarantees and high service availability, as required by premium
services such as FC/MPLS.
2.3. Traffic Engineering
The transport of FC frames over a PSN network requires the operator
not only to optimize the use of bandwidth resources, but also to
define an explicit path over which availability and performance can
Roth, et al. Expires - December 2006 [Page 4]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
be guaranteed. This capability is offered by other interconnect
technologies such as ATM or SONET transport network technologies.
FC/MPLS defines the mapping of FC frames into an MPLS PW, implicitly
assuming the use of MPLS-TE for the explicit provisioning of an FC PW
over the MPLS-based PSN. This enables the operator to guarantee the
performance and availability of the emulated FC link.
FC requires a reliable transmission mechanism between FC entities.
This implicitly assumes a lossless media with high availability and
low packet loss. This, however, cannot always be guaranteed in best
effort networks where FC frames are at times transported over sub-
optimal paths. Bearing this in mind, FC/MPLS relies on MPLS-TE to
create an emulated FC link over a packet-oriented transport network,
effectively enabling network operators to establish an explicit path
over which reliable frame forwarding can be guaranteed.
2.4. Security
FC/MPLS is designed to transparently support the forwarding of FC
frames received from the local FC port, into a pre-established FC PW,
thus effectively making the FC/MPLS emulated path less susceptible to
attacks when compared to, e.g., IP public networks.
3. Reference Model
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
[RFC4447].
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
Roth, et al. Expires - December 2006 [Page 5]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
+-----+ | | 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
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].
Roth, et al. Expires - December 2006 [Page 6]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
4. Encapsulation
This specification provides port to port transport of FC encapsulated
traffic. The following FC connections (as specified in [FC-BB]) 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"
[RFC4385] MUST be used for FC PW to facilitate the transport of short
packets. 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|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
[RFC4385] and [FRAG].
The length field MUST be used for packets shorter than 64 bytes. Its
processing must follow the rules defined in [RFC4385].
The sequence number can be used to guarantee ordered frame delivery.
The sequence number is a 16 bit, unsigned integer. The sequence
number value 0 is used to indicate that the sequence number check
algorithm is not used.
4.1.1. Setting the sequence number
For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
frame sequencing then the following procedures should be used:
- the initial frame transmitted on the PW MUST use sequence number 1
- subsequent frames MUST increment the sequence number by one for
each frame
Roth, et al. Expires - December 2006 [Page 7]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
- when the transmit sequence number reaches the maximum 16 bit
value (65535) the sequence number MUST wrap to 1
If the transmitting router PE1 does not support sequence number
processing, then the sequence number field in the control word MUST
be set to 0.
4.1.2. Processing the sequence number
If a router PE2 supports receive sequence number processing, then the
following procedures should be used:
When a PW is initially set up, the "expected sequence number"
associated with it MUST be initialized to 1.
When a frame is received on that PW, the sequence number should be
processed as follows:
- if the sequence number on the frame is 0, then the sequence
number check is skipped.
- otherwise if the frame sequence number >= the expected sequence
number and the frame sequence number - the expected sequence
number < 32768, then the frame is in order.
- otherwise if the frame sequence number < the expected sequence
number and the expected sequence number - the frame sequence
number >= 32768, then the frame is in order.
- otherwise the frame is out of order.
If a frame passes the sequence number check, or is in order then, it
can be delivered immediately. If the frame is in order, then the
expected sequence number should be set using the algorithm:
expected_sequence_number := frame_sequence_number + 1 mod 2**16
if (expected_sequence_number = 0) then expected_sequence_number := 1;
Packets which are received out of order MAY be dropped or reordered
at the discretion of the receiver.
If a PE router negotiated not to use receive sequence number
processing, and it received a non zero sequence number, then it
SHOULD send a PW status message indicating a receive fault, and
disable the PW.
4.2. MTU Requirements
Roth, et al. Expires - December 2006 [Page 8]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
The PSN MUST be able to transport the largest Fibre Channel
encapsulation frame, including the overhead associated with the
tunneling protocol. The methodology described in [FRAG] MAY be used
to fragment Fibre Channel encapsulated frames that exceed the PSN
MTU. However if [FRAG] is not used then the network MUST be
configured with a minimum MTU that is sufficient to transport the
largest encapsulation frame.
4.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. The NSP header includes
packet type marking. This is performed by the NSP 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].
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 |
+---------------+---------------+---------------+---------------+
| |
+---- ----+
Roth, et al. Expires - December 2006 [Page 9]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
| |
+---------------+---------------+---------------+---------------+
| 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
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.
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. Signaling of FC Pseudo Wires
[PWE3-CONTROL] specifies the use of the MPLS Label Distribution
Protocol, LDP, as a protocol for setting up and maintaining pseudo
wires. 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 8
below.
The control word is REQUIRED for FC pseudo-wires. 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 pseudo-wire MUST not be
established and a Label Release MUST be sent with an “Illegal C-Bit”
status code [PWE3-CONTROL].
There are no specific Interface Parameters for FC pseudo-wires. If
fragmentation is used and the receiver is able to reassemble
fragments then fragmentation indicator parameter MAY be present in
the Interface Parameter Sub-TLV.
Roth, et al. Expires - December 2006 [Page 10]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
6. Congestion Control
FC PW traffic can be transmitted over networks that may experience
congestion due to statistical multiplexing. When congestion
conditions are experienced frames may be discarded within the PSN.
Congestion control mechanism is required to prevent congestion
collapse and provide fairness among the different connections.
Fairness is usually defined with respect to TCP flow control
[RFC2914]. The FC PW relies on a congestion control mechanism that
provides TCP-friendly behavior by controlling the transmission rate
into the PSN by a rate shaper, whose output rate is a function of
network congestion.
Frame loss within the PSN also requires a reliable transmission
mechanism in the PE to support faithful emulation of FC service,
providing in-order, no-loss transport of FC traffic between CE1 and
CE2. The reliable transmission is a sliding-window selective
retransmission (SR) mechanism to allow efficient retransmission of
lost frames. This was standardized for FC transport in [FC-BB]. The
SR mechanism also provides congestion indication (i.e. Frame loss
events) to the rate control mechanism.
6.1. Rate Control
The rate control mechanism provides adaptive shaper control in
response to network congestion indications. The rate shaper is
configured with BW attributes, such as CIR and EIR, assigned to the
FC PW service. The rate control operation is based on [RFC3448]. In
the following sections the applicability of [RFC3448] to FC PW is
analyzed, and rate control operation is detailed.
[RFC3448] is a receiver-based congestion control mechanism, where the
congestion control information (i.e., the loss event rate) is
calculated by the receiver. In FC PW, on the other hand, the
congestion control information is calculated by the sender. This
approach is more appropriate for the point-to-point nature of FC PW.
This sender-based approach is also mentioned in [RFC3448] as a
possible variant of the protocol.
6.1.1. Protocol Mechanism
In accordance with [RFC3448] the actual allowed sending rate is
directly computed by a throughput equation, as a function of lost
frames and round trip time. In general, the congestion control
mechanism works as follows:
o The receiver detects lost frames and feeds this information
Roth, et al. Expires - December 2006 [Page 11]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
back to the sender as part of the SR mechanism.
o The sender calculates the frame loss probability and measures
the round-trip time (RTT) as defined in [FC-BB].
o The lost frame probability and RTT are then fed into the
throughput equation, calculating the acceptable transmission
rate.
o The sender then adjusts its transmission rate to match the
calculated rate in accordance with the service BW attributes
(CIR, EIR).
As the CIR is guaranteed, the throughput equation controls only the
excess transmission rate. The parameters of the throughput equation
are set as follows:
o The packet size (s) is replaced by the SR window size (K) in
bytes as defined in [FC-BB].
o The retransmission timeout (t_RTO) is replaced by the T1 timer
of the SR mechanism as defined in [FC-BB].
o The number of frames acknowledged by a single SR
acknowledgment frame (b) is set in accordance with [RFC3448] as
b = 1. Different implementation MAY use delayed acknowledgement
by increasing the value of b.
Frame loss probability (p) is calculated as specified in Section
6.1.2. RTT (R) is measured by the NSP as defined in [FC-BB].
6.1.2. Data Sender Protocol
The data sender sends a stream of data frames to the data receiver at
a controlled rate. When a feedback frame is received from the data
receiver, the data sender calculates the frame loss probability and
changes its sending rate accordingly. If the sender does not receive
a feedback frame during a timeout period, it cuts its sending rate in
half. This is achieved by the SR T1 timer.
We specify the sender-side protocol in the following steps:
o The sender behavior when a feedback frame is received.
o The sender calculation of the frame loss probability.
o The sender behavior when a feedback frame is not received for
a timeout period.
Roth, et al. Expires - December 2006 [Page 12]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
The sender rate shaper is initialized to transmit at the CIR. The SR
mechanism is also initialized by resetting the sequence numbers (as
defined in [FC-BB]).
The sender calculates RTT in accordance with [RFC3448], based on
delay measurement frames transmitted by the NSP (as defined in [FC-
BB]).
The sender calculates the frame loss probability based on feedback
frames generated by the receiver. A feedback frame with accordance to
the SR mechanism defined in [FC-BB] is one of the following:
o Receiver Ready (RR) – a frame that includes the N(R) counter to
acknowledge the sender frames up to frame N(R).
o Receiver Not Ready (RNR) – a frame that includes the N(R)
counter to acknowledge the sender frames up to frame N(R), and
pause the sender from sending additional frames.
o Selective Reject (SREJ) – a frame that includes lost frames
indication (sequence numbers).
When the sender receives a feedback frame it re-calculates the frame
loss probability. RR and RNR will effectively decrease the frame loss
probability due to no frame loss. On the other hand, reception of a
SREJ frame tends to increase the frame loss probability. An
implementation MAY consider sending feedback frames, in a controlled
network environment, with expedite forwarding (EF) CoS to assure
delivery.
After the frame loss probability is updated, the sender calculates a
new transmission rate for the rate shaper. The transmission rate is
calculated as: Rate = CIR + X, where X is the outcome of the
throughput equation as specified in [RFC3448]. If the calculated rate
exceeds the Peak Information Rate (PIR = CIR + EIR) it is set equal
to the PIR.
No feedback in accordance with [RFC3448] is defined as T1*N2, where
N2 is defined as the number of times the sender initiates a recovery
procedure according to [FC-BB]. When the sender does not receive a
feedback for such an interval it halves it throughput as defined in
[RFC3448].
6.1.3. Data Receiver Protocol
The data receiver receives a stream of data frames from the data
sender, generates SR feedback frames (RR, RNR and SREJ), and sends
Roth, et al. Expires - December 2006 [Page 13]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
them to the data sender. The details of feedback frames generation
and transmission are specified in [FC-BB].
6.2. Selective Retransmission
The selective retransmission mechanism provides efficient
retransmission of lost frames to enable faithful emulation of FC
service, with no frame loss experienced by the CE. The proposed
selective retransmission mechanism was standardized for FC transport
in [FC-BB].
7. 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 [RFC4447] [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.
8. Applicability Statement
FC PW allows the transport of point-to-point Fibre Channel links
while saving PSN bandwidth.
- The pair of CE devices operates as if they were connected by an
emulated FC link. In particular they react to Primitive Sequences
on their local ACs in the standard way.
- The PSN 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 the BW.
FC PW traffic can traverse controlled (i.e., providing committed
information rate for the service) networks and uncontrolled (i.e.,
providing excess information rate for the service) networks. In case
of FC PW traversing an uncontrolled network, it SHOULD provide TCP-
friendly behavior under network congestion (refer to Congestion
Control section for further details).
Faithfulness of a FC PW may be increased if the carrying PSN is
Diffserv-enabled and implements a per-domain behavior (PDB, defined
in [RFC3086]) that guarantees low loss, low re-ordering events and
low delay. The NSP may include mechanisms to reduce the effect of
these events on the FC service. These mechanisms are out of the scope
of this document.
Roth, et al. Expires - December 2006 [Page 14]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
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 defined by the PSN behavior. However, the
NSP MAY implement a mechanism to convey the PW status to the CE, to
enable faster handling of the PSN outage. Moreover, the NSP MAY
implement egress buffer and packet reordering mechanism to increase
the emulated service resiliency to fast PSN rerouting events. As a
function of the NSP this is out of the scope of this document.
9. IANA considerations
A new PW type, named "FC Port Mode" is requested from IANA. The next
available value is requested.
10. 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.
[RFC3086] Nichols, K., et al, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their
Specification)", RFC 3086, April 2001.
[RFC3448] Handley, M., et al, "TCP Friendly Rate Control (TFRC):
Protocol Specification", RFC 3448, January 2003.
[RFC4447] Martini, L., et al, "Pseudowire Setup and Maintenance
using the Label Distribution Protocol (LDP)", RFC 4447,
April 2006.
[RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word for use over an MPLS PSN", RFC 4385,
February 2006.
[FRAG] Malis, A., Townsley, M., "PWE3 Fragmentation and
Reassembly", draft-ietf-pwe3-fragmentation-09.txt,
September 2005, Work in Progress.
[FC-BB] "Fibre Channel Backbone-3", T11/Project 1639-D/Rev 6.9,
August 2005.
Roth, et al. Expires - December 2006 [Page 15]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
requirement Levels", BCP 14, RFC 2119, March 1997.
11. Informative references
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", RFC 3668, February 2004.
[RFC3821] M. Rajogopal, E. Rodriguez, “Fibre Channel over TCP/IP
(FCIP)”, RFC 3821, July 2004.
[RFC3643] R. Weber, et al, “Fibre Channel (FC) Frame
Encapsulation”, RFC 3643, December 2003.
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
September 2000.
[RFC2581] Allman, M., et al, “TCP Congestion Control”, RFC 2581,
April 1999.
[RFC4448] Martini, L., et al, “Encapsulation Methods for Transport
of Ethernet over MPLS Networks”, RFC 4448, April 2006.
[CEP] Malis, A., et al, “SONET/SDH Circuit Emulation Over
Packet (CEP)", draft-ietf-pwe3-sonet-13.txt, May 2006,
Work in Progress.
[Frame] Malis, A., Martini, L., et al, "Encapsulation Methods
for Transport of Frame Relay over MPLS Networks", draft-
ietf-pwe3-frame-relay-07.txt, February 2006, Work in
Progress.
[ATM] Martini, L., et al, “Encapsulation Methods for Transport
of ATM over MPLS Networks”, draft-ietf-pwe3-atm-encap-
11.txt, June 2006, Work in Progress.
12. Author's Addresses
Moran Roth
Corrigent Systems
126, Yigal Alon st.
Tel Aviv, ISRAEL
Phone: +972-3-6945433
Email: moranr@corrigent.com
Ronen Solomon
Roth, et al. Expires - December 2006 [Page 16]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
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
13. Contributing Author Information
David Zelig
Corrigent Systems
126, Yigal Alon st.
Tel Aviv, ISRAEL
Phone: +972-3-6945273
Email: davidz@corrigent.com
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.
Roth, et al. Expires - December 2006 [Page 17]
INTERNET DRAFT draft-ietf-pwe3-fc-encap-01.txt June 2006
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
Copyright (C) The Internet Society (2006).
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 2006 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 09:55:47 |