INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 PWE3 Internet Draft Moran Roth (Ed.) Document: draft-roth-pwe3-fc-encap-01.txt Ronen Solomon Expires: April 2006 Corrigent Systems Munefumi Tsurusawa KDDI October 2005 Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 - April 2006 [Page 1] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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...........................................11 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 - April 2006 [Page 2] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 3] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 4] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 5] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 ^ | +----+ +----+ | | ^ | | 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 - April 2006 [Page 6] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 7] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 8] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 9] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 10] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 SHOULD provide TCP-friendly behavior under network congestion. 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 packets reordering mechanism to increase the emulated service resiliency to fast PSN rerouting events. 8. IANA considerations A new PW type, named "FC Port Mode" is requested from IANA. The next available value is requested. Roth, et al. Expires - April 2006 [Page 11] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 [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. Roth, et al. Expires - April 2006 [Page 12] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 [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. Tel Aviv, ISRAEL Phone: +972-3-6945273 Email: davidz@corrigent.com Leon Bruckman Corrigent Systems 126, Yigal Alon st. Tel Aviv, ISRAEL Roth, et al. Expires - April 2006 [Page 13] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 Phone: +972-3-6945694 Email: leonb@corrigent.com Luis Aguirre-Torres Corrigent Systems 101 Metro Drive Ste 680 San Jose, CA 95110 Phone: +1 408-392-9292 Email: Luis@corrigent.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). Roth, et al. Expires - April 2006 [Page 14] INTERNET DRAFT draft-roth-pwe3-fc-encap-01.txt October 2005 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 - April 2006 [Page 15]