[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-roth-pwe3-fc-encap) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6307

               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  PWE3
                  Internet Draft                                      Moran Roth (Ed.)
                  Document: draft-ietf-pwe3-fc-encap-00.txt              Ronen Solomon
                  Expires: July 2006                                 Corrigent Systems
                                                                    Munefumi Tsurusawa
                                                                                  KDDI

                                                                          January 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 - July 2006                  [Page 1]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 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..................................................6
                     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. Security Considerations.......................................10
                  7. Applicability Statement.......................................11
                  8. IANA considerations...........................................12
                  9. References....................................................12
                  10. Informative references.......................................12
                  11. Author's Addresses...........................................13
                  12. Contributing Author Information..............................13


               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 [ETH], Frame
                  Relay [FRAME], ATM [ATM] and SONET/SDH [CEP] services. Another such
                  service, which has yet to be addressed, is the transport of Fibre
                  Channel frames over the PSN. This will allow network service
                  providers to transparently carry Fibre Channel services over the
                  packet-oriented transport network, along with the aforementioned data
                  and TDM services.






               Roth, et al.             Expires - July 2006                  [Page 2]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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.

                  The following sections describe some of the key carrier requirements
                  for transporting FC frames over an MPLS-based PSN.




               Roth, et al.             Expires - July 2006                  [Page 3]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



               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 CIR and PIR, 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
                  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



               Roth, et al.             Expires - July 2006                  [Page 4]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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 [PW-
                  MPLS].

                  A FC PW emulates a single FC link between exactly two endpoints. This
                  document specifies the emulated PW encapsulation for FC.

                  The following figure describes the reference models which are derived
                  from [RFC3985] to support the FC PW emulated services.

                           |<-------------- Emulated Service ---------------->|
                           |                                                  |
                           |          |<------- Pseudo Wire ------>|          |
                           |          |                            |          |
                           |          |    |<-- PSN Tunnel -->|    |          |
                           |          V    V                  V    V          |
                           V   AC     +----+                  +----+    AC    V
                     +-----+    |     | PE1|==================| PE2|     |    +-----+
                     |     |----------|............PW1.............|----------|     |
                     | CE1 |    |     |    |                  |    |     |    | CE2 |
                     |     |----------|............PW2.............|----------|     |
                     +-----+  ^ |     |    |==================|    |     | ^  +-----+


               Roth, et al.             Expires - July 2006                  [Page 5]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                           ^  |       +----+                  +----+     | |  ^
                           |  |   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].


               4.
 Encapsulation




               Roth, et al.             Expires - July 2006                  [Page 6]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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" [PW-
                  CW] 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 [PW-
                  CW] and [FRAG].

                  The length field MUST be used for packets shorter than 64 bytes. Its
                  processing must follow the rules defined in [PW-CW].

                  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
                  - 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


               Roth, et al.             Expires - July 2006                  [Page 7]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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

                  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


               Roth, et al.             Expires - July 2006                  [Page 8]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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     |
                  +---------------+---------------+---------------+---------------+
                  |                                                               |
                  +----                                                       ----+
                  |                                                               |
                  +---------------+---------------+---------------+---------------+
                  |     K28.5     |     Dxx.y     |     Dxx.y     |     Dxx.y     |
                  +---------------+---------------+---------------+---------------+


               Roth, et al.             Expires - July 2006                  [Page 9]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006




                      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 [PW-MPLS], or through PW OAM
                  mechanisms MUST be mapped to emulated signal failure indications.
                  The FC link failure indication is performed by the NSP, as defined by
                  [FC-BB], and is out of the scope of this document.


               5.
 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.


               6.
 Security Considerations




               Roth, et al.             Expires - July 2006                 [Page 10]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  This document specifies only encapsulations, and not the protocols
                  used to carry the encapsulated packets across the PSN. Each such
                  protocol may have its own set of security issues [PW-MPLS] [RFC3985],
                  but those issues are not affected by the encapsulations specified
                  herein. Note that the security of the emulated service will only be
                  as good as the security of the PSN.


               7.
 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 committed and excess information rate for the service)
                  networks. In case of FC PW traversing through an uncontrolled
                  network, it SHOULD provide an equation-based congestion control
                  mechanism under network congestion. Equation-based congestion control
                  uses a control equation that explicitly gives the maximum acceptable
                  sending rate (i.e., rate shaping) as a function of the recent loss
                  event rate. The sender adapts its sending rate, guided by this
                  control equation, in response to feedback from the receiver. Rate
                  shaping provides low-pass filtering traffic bursts which reduces the
                  frame drop probability. This is a function of the NSP, and is out of
                  the scope of this document.

                  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.

                  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


               Roth, et al.             Expires - July 2006                 [Page 11]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  the emulated service resiliency to fast PSN rerouting events. As a
                  function of the NSP this is out of the scope of this document.


               8.
 IANA considerations

                  A new PW type, named "FC Port Mode" is requested from IANA. The next
                  available value is requested.


               9.
 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.

                  [PW-MPLS]   Martini, L., et al, "Pseudowire Setup and Maintenance
                               using LDP", draft-ietf-pwe3-control-protocol-17.txt,
                               June 2005, Work in Progress.

                  [PW-CW]     Bryant, S., Swallow, G., McPherson, D., "PWE3 Control
                               Word for use over an MPLS PSN", draft-ietf-pwe3-cw-
                               05.txt, July 2005, Work in Progress.

                  [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.

                  [BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                               requirement Levels", BCP 14, RFC 2119, March 1997.


               10.
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


               Roth, et al.             Expires - July 2006                 [Page 12]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006




                  [RFC3643]   R. Weber, et al, “Fibre Channel (FC) Frame
                               Encapsulation”, RFC 3643, December 2003

                  [CEP]       SONET/SDH Circuit Emulation Service Over Packet (CEP)",
                               draft-ietf-pwe3-sonet-11.txt, May 2005, Work in
                               Progress.

                  [Frame]     "Frame Relay over Pseudo-Wires",draft-ietf-pwe3-frame-
                               relay-05.txt, April 2005, Work in Progress.

                  [ATM]       “Encapsulation Methods for Transport of ATM Cells/Frame
                               Over IP and MPLS Networks, draft-ietf-pwe3-atm-encap-
                               09.txt, June 2005, Work in Progress.

                  [ETH]       Encapsulation Methods for Transport of Ethernet Over
                               MPLS Networks, draft-ietf-pwe3-ethernet-encap-10.txt,
                               June 2005, Work in Progress.


               11.
Author's Addresses

                  Moran Roth
                  Corrigent Systems
                  126, Yigal Alon st.
                  Tel Aviv, ISRAEL
                  Phone:  +972-3-6945433
                  Email: moranr@corrigent.com

                  Ronen Solomon
                  Corrigent Systems
                  126, Yigal Alon st.
                  Tel Aviv, ISRAEL
                  Phone:  +972-3-6945316
                  Email: ronens@corrigent.com

                  Munefumi Tsurusawa
                  KDDI R&D Laboratories Inc.
                  2-1-15 Ohara, Kamifukuoka-shi
                  Saitama, Japan
                  Phone : +81-49-278-7828


               12. Contributing Author Information

                  David Zelig
                  Corrigent Systems
                  126, Yigal Alon st.


               Roth, et al.             Expires - July 2006                 [Page 13]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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.

                  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


               Roth, et al.             Expires - July 2006                 [Page 14]


               INTERNET DRAFT     draft-ietf-pwe3-fc-encap-00.txt        January 2006



                  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 - July 2006                 [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/