Internet-Draft Generalized Ethernet Pseudowire July 2008 Internet Draft Document Vach Kompella Category: Standards Track Florin Balus Expires: January 2009 Alcatel-Lucent Andrew Malis Verizon Shane Amante Level 3 Giles Heron British Telecom July 2008 Generic Ethernet Pseudowire draft-vkompella-pwe3-ethernet-pw-bis-01.txt 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. This Internet-Draft will expire in January 2009. Copyright Notice Copyright (C) The IETF Trust (2008). V. Kompella Expires January 2009 [Page 1] Internet-Draft Generalized Ethernet Pseudowire July 2008 Abstract This draft proposes a simpler approach to handling various encapsulations of Ethernet packets over a pseudowire, over the existing Ethernet Pseudowire definition in [RFC4448]. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction In this draft, we describe a methodology for encapsulating Ethernet packets in pseudowires that eliminates the need for multiple encapsulation formats and pseudowire code-points when Ethernet formats change. This draft extends the concepts already published in [RFC4448]. [RFC4448] defines two different pseudowire types for Ethernet packets, one where the packet transported over the pseudowire must have a service delimiting VLAN tag (Ethernet tagged type), and the other where it does not need to have one (Ethernet type) as per [IANA PWE3]. The original justification for the tagged PW type came from the need to accommodate routers that could not handle standard Ethernet functions like imposing, stripping or rewriting VLAN tags. This draft has been written in response to the following statements from [RFC4448] and consequent concerns that as new Ethernet formats (such as Provider Backbone Bridging, PBB I-tag [802.1ah]) are defined, corresponding pseudowires have to be defined: - For an Ethernet VLAN PW, VLAN tag rewrite can be achieved by NSP at the egress PE, which is outside the scope of this document ([RFC4448], Section 3). - The Ethernet or Ethernet VLAN PW only supports homogeneous Ethernet frame type across the PW; both ends of the PW must be either tagged or untagged. Heterogeneous frame type support achieved with NSP functionality is outside the scope of this document ([RFC4448], Section 3). This document proposes a Generic Ethernet PW (GE-PW) that extends the definition of Ethernet PWs and their usage in the existing L2VPNs (VPWS, VPLS) and simplifies the development of future solutions that require transport of Ethernet frames over a pseudowire. V. Kompella Expires January 2009 [Page 2] Internet-Draft Generalized Ethernet Pseudowire July 2008 2. The Generalized Ethernet Pseudowire To define the Generalized Ethernet Pseudowire (GE-PW) we need to describe the following functions: - the packets eligible to be placed in a GE-PW - the processing functions outside the scope of the GE-PW - the processing functions within the scope of the GE-PW 2.1. Eligible Packets in the GE-PW Any ethernet packet defined by the IEEE is an eligible packet for the GE-PW, regardless of the type of tags it contains - e.g. IEEE 802.1Q, 802.1ad, 802.1ah tags. The Ethernet header is defined with a set of well defined code points that can be used by the NSP to identify the type of tag and the following header fields and to process the frame accordingly. A new Interface Parameter sub-TLV is defined to describe the capabilities of the NSP function to adapt different ethernet encapsulations as packets arrive from the pseudowire and are delivered to the attachment circuit. Section 4 describes the applicability and the format for the new sub-TLV. 2.2. Processing outside the scope of the GE-PW When an ethernet packet is received on an attachment circuit (AC), it may be processed before being passed to the PW termination function. This processing is done by the NSP function which has the responsibility of removing service delimiting encapsulations on the packet, and identifying the PW that the packet is bound for. When a packet arrives on a PW, the PW service label is used to identify the particular service instance and subsequently the NSP function that is applied to the ethernet packet at the egress PE. The NSP function puts on the appropriate ethernet encapsulation before passing the packet on to the attachment circuit(s) associated with the NSP. The processing of the Ethernet frames at the ingress and egress NSPs are outside the scope of the GE-PW. 2.3. Processing within the scope of the GE-PW A packet passed to the PW termination function by the ingress NSP at the ingress PE is encapsulated with the appropriate PW label and is passed to the PSN function for encapsulation and transport to the V. Kompella Expires January 2009 [Page 3] Internet-Draft Generalized Ethernet Pseudowire July 2008 egress PE. A packet arriving on a pseudowire egress has its PW label popped, and the resulting packet is passed to the appropriate NSP instance. 3. Detailed processing steps There are four main processing points in using a pseudowire: the ingress NSP function, the ingress PW termination function, the egress PW termination function, and the egress NSP function. Although just the PW termination functions are relevant for GE-PW, this section discusses how the GE-PW can be used with different types of existing NSPs to emulate existing and future services. In order to more clearly illustrate how a GE-PW may be used to provide pseudowire services, we introduce the following terms. These terms are to be used as a guideline to understanding the behavior of a GE-PW, and in no way define an implementation: - In-NSP(packet, options): the ingress NSP function, includes the ingress attachment circuit (AC) function - In-PW(packet, options): the ingress PW termination function - Out-PW(packet, options): the egress PW termination function - Out-NSP(packet, options): the egress NSP function, includes the egress AC function In addition, we define the pseudowire context (PWC) as the construct which has, at ingress, the following information: - the incoming encapsulation of the packet - the In-NSP function to be applied on the packet - the In-PW termination function to be applied - the ingress PSN encapsulation information to be applied and at egress: - the Out-PW termination function to be applied - the Out-NSP function to be applied on the packet - the outgoing encapsulation of the packet on the attachment circuit Using the above functions, we will define actions at the various stages of the packet through the network that affect its behavior. In particular, we will show the capabilities in describing the two existing Ethernet pseudowires, and introduction of a number of standard VLL service types that are enabled as a consequence of implementing the GE-PW methods. V. Kompella Expires January 2009 [Page 4] Internet-Draft Generalized Ethernet Pseudowire July 2008 As the packet arrives from the customer, at the In-NSP function, the NSP may remove the FCS and any extraneous packet header information that is locally significant [RFC4448]. The optional method described in [RFC4720] can be used to achieve payload integrity transparency. In particular, the function of the In-NSP is to render the packet ready for consumption by the remote Out-NSP function. In other words, the In-NSP must replace, remove or impose VLAN tags, PBB I- tag or any required Ethernet headers so that the packet is recognizable by the egress NSP. It performs also functions specific to the type of native service that is rendered at the ingress PE, for example MAC switching, MAC learning, packet replication for VPLS. Finally, the In-NSP function also identifies the pseudowire that is associated with the attachment circuit over which the packet arrived. If, for example, the packet arrived on a VLAN tagged port, and the VLAN tag identifies the attachment circuit, then the In-NSP is responsible for recovering the VLAN tag and identifying the attachment circuit. It is out of the scope of this document to define how attachment circuits are represented and associated with pseudowires. The resulted Ethernet frame, as delivered by the In-NSP is not modified in any way by the In-PW function. The In-PW termination simply imposes the PW encapsulation for the packet. This may be introducing the optional control word and its fields, depending on how the pseudowire was configured and which options were negotiated. Following this step, the PW label for the packet is imposed. Subsequently, the appropriate forwarding engine component imposes the PSN encapsulation. How the PSN encapsulation is determined and imposed for a particular pseudowire is out of the scope of this document. Once the packet is delivered to the network, the PSN encapsulation directs the packet towards the egress endpoint of the pseudowire. At the egress, the PSN encapsulation is removed. Following this, the packet is delivered to the Out-PW termination function. The Out-PW function removes the PW encapsulation. This involves removing both the PW label and the optional control word (if negotiated and present). In addition, the PW label is used to identify an Out-NSP function associated with one or more attachment circuit(s) that is/are the outgoing interface(s) to the customer. The packet is handed to the Out-NSP function which will complete processing and hand the packet to the egress attachment circuit. The Out-NSP function has the responsibility for processing the packet in order to prepare it for the egress attachment circuit. This would involve, e.g., the insertion, deletion or replacement of different Ethernet tags or other Ethernet encapsulation so that it can accommodate different types of ACs, for example port, tagged V. Kompella Expires January 2009 [Page 5] Internet-Draft Generalized Ethernet Pseudowire July 2008 with one VLAN, tagged with multiple VLANs (QinQ [802.1ad]) or PBB I- tags. There are a number of functions that are out of the scope of this specification. The primary reason they are out of scope is that they are implementation dependent, and do not relate to the standard definition of the Generalized Ethernet Pseudowire (GE-PW). For example, whether the incoming attachment circuit has a pointer to the In-NSP function or an index into a table, or how the pseudowire is identified within the forwarding engine are not material to the definition of the GE-PW. The definition of what the NSP function has to perform is also a matter of local configuration. 4. Control Plane All the PW Setup and Maintenance procedures described in [RFC4447] apply to the GE-PW. There is no need for a new PW type. The Ethernet type (0x0005) may be used [IANA PWE3] as the new GE-PW procedures are backwards compatible with an existing implementation using Ethernet type PW - see section 6. The function of an Ethernet tagged PW can be also emulated in the NSPs with a GE-PW. There might be some network scenarios where the required NSP capabilities need to be signaled between PEs. This might be the case for certain implementations that need to know what kind of NSP they need to instantiate for certain PW. Also in some scenarios the Service Providers might need to make sure the capabilities of the related NSPs match. An optional NSP capabilities sub-TLV for the Interface Parameters TLV [RFC4447] is defined to allow the signaling of NSP capabilities between Layer 2 PEs. The NSP Capabilities sub-TLV is included in the related LDP messages for PW setup and maintenance if the transmitting PE needs to verify that the remote NSP is capable of performing certain functionality. On reception of the NSP Capabilities sub-TLV a Layer 2 PE MUST reject the PW Setup if it does not support or if the related NSP is not properly configured to support any of the required NSP capabilities. If the Layer 2 PE does not understand the NSP Capabilities sub-TLV, it should continue the processing of the interface parameters while silently discarding the unknown interface parameter as per [RFC4447] section 5.5. The format of the NSP sub-TLV follows the standard format defined for all Interface Parameter sub-TLVs [RFC4447]: 0 1 2 3 V. Kompella Expires January 2009 [Page 6] Internet-Draft Generalized Ethernet Pseudowire July 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Sub-TLV Length | Capability 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability 1 (cont) | | " | | Capability n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type for NSP Capabilities sub-TLV is to be assigned by IANA (0x0D to be confirmed). The following field defines the value length in octets. Next is one or a list of NSP capabilities. Each Capability is coded as 1 byte code point followed by an 1 byte length field (length of the capability parameters in octets)whereas the rest of the value field is used to indicate parameters specific to the required capability ID. The following code points are defined in this document: - 001, Service delimiting VLAN tag required; length = 2 octets, value identifies the (tag) Ethernet type (e.g. IEEE 802.1q, 802.1ad, 802.1ah) - 002, Tag rewrite; length - 2 octets; value identifies the (tag) Ethernet type, same as for the above Addditional code points for the NSP Capabilities are to be added as the applications are being defined. 5. The Control Word The OPTIONAL control word specified in [RFC4385] MAY be used for the GE-PW. 6. Backwards Compatibility with existing Ethernet PW implementations The NSP of a GE-PW capable PE that needs to interoperate with older implementations may be manually configured to fully emulate the behavior of an existing Ethernet PW NSP as described in section 4.1 and 4.4 of [RFC4448]. The NSP Capabilities sub-TLV may be also used to automatically identify the old Ethernet PW implementation. The GE-PW capable PE may use the received NSP Capabilities indication to identify the regular (Ethernet or Ethernet VLAN) PW implementations. The GE-PW capable PE MUST always include the NSP capability sub-TLV in the PW setup message. If the PW signaling received from the remote PE does not contain the NSP Capability sub-TLV, the local PE switches to regular PW mode. If the other Layer 2 PE does not V. Kompella Expires January 2009 [Page 7] Internet-Draft Generalized Ethernet Pseudowire July 2008 understand the NSP Capabilities sub-TLV, it should continue the processing of the interface parameters while silently discarding the unknown interface parameter as per [RFC4447] section 5.5. 7. Emulating existing Ethernet Services The rationale for redefining the two variants of the Ethernet pseudowires is that the GE-PW is a more powerful construct that subsumes both of them, prevents the future proliferation of other Ethernet PW types and allows the definition of many more services than are allowed by strictly following the existing pseudowire definitions. The following examples demonstrate that the right set of NSP and PW functions yield not just the known VPWS, VPLS behaviors induced by the two existing Ethernet pseudowires, but additional models used by service providers, that are not strictly compliant to the existing pseudowires. 7.1. GE-PW applicability to Ethernet PW The GE-PW allows for emulation of an Ethernet point-to-point service between different types of Ethernet Attachment Circuits by simply emulating in the ingress NSP the required behavior. Specifically the attachment circuits (ACs) may be defined at the PEs to represent the whole port, one or more VLAN(s) (tagged, one service delimiting VLAN) or a VLAN combination (QinQ/[802.1ad], tagged with two service delimiting VLANs) and are mapped to the point-to-point NSP function in each PE through local association. As a result the packet arriving on the local AC is classified as belonging to an ingress NSP who may be configured to remove/rewrite/add one or more VLAN tags before forwarding the packet to the GE-PW termination function that will encapsulate it for transport over PSN core. Similarly the egress NSP can manipulate encapsulation received over GE-PW, adding, replacing or removing one or more tags of different types as desired to accommodate different types of egress Ethernet interfaces and AC definitions, for example port, tagged with one VLAN, tagged with multiple VLANs (QinQ [802.1ad]). A default behavior for the AC processing function of the NSPs corresponding to the Ethernet PW type can be defined as follows: - Assume one or more service delimiting tags are used by one of the NSPs (NSP1) to identify the AC. The other NSP (NSP2) might use a different set of service delimiting tags to identify the AC. V. Kompella Expires January 2009 [Page 8] Internet-Draft Generalized Ethernet Pseudowire July 2008 - If a packet arrives at NSP1, the related in-NSP AC function removes the service delimiting tags after AC identification then performs the rest of the operations as described above. - At the NSP2, the corresponding out-NSP AC function adds for each AC the local service delimiting tags. - This default behavior provides flexibility of supporting interworking between any kind of ACs without one PE needing to know what the remote PEs is using for AC identification. 7.2. GE-PW Applicability to Ethernet VLAN PW Starting from the default behavior outlined in the previous section for GE-PW, one can emulate the Ethernet VLAN mode by simply configuring the in-NSP to insert a service delimiting VLAN tag before sending the packet to the in-PW processing function. Alternatively the need for service delimiting VLAN tag can be indicated from the egress PE via the NSP capability TLV using code point 001 as described in the Control Plane section. The type of tag to be inserted (IEEE 802.1q, IEEE 802.1ad or proprietary) can be specify in the parameter field of the capability. 7.3. GE-PW Applicability to VPWS and VPLS The GE-PW can be used to serve the interconnect needs for the VPWS and VPLS Forwarders. The previous section discussed how the GE-PW can replace the existing Ethernet PW types from a point to point forwarding perspective, handling also the VLAN tags on a per local AC basis. VPWS is really a collection of point-to-point virtual circuits, each of them built as an individual PW context with full (in-NSP, in-PW, out-PW, out NSP) functions. As demonstrated in the previous two sections the GE-PW construct can emulate either of the existing behaviors (Ethernet or Ethernet VLAN PWs) for each of the individual virtual circuits, providing this way full support for any possible VPWS combination supported by the existing PW types. For VPLS the NSPs will have to replicate the same in-NSP AC, out-NSP AC functions but for multiple ACs, handling also the Ethernet switching functions (e.g. MAC switching, MAC Learning, Packet Replication) as described in [RFC4664] and [RFC4762]. Translating the default behavior for the Ethernet PW type that means each in-NSP will remove the tags configured for AC identification and each out- NSP will add the tags configured for AC identification providing flexible support for any AC combination in the same VPLS. V. Kompella Expires January 2009 [Page 9] Internet-Draft Generalized Ethernet Pseudowire July 2008 7.4. GE-PW for point-to-point transport of PBB over Pseudowires When a PW interconnects two PBB access networks (see Figure 1), there may be a need to use the PBB ISID Tag (I-tag) [802.1ah] to perform the mapping to/from ACs. The PBB I-tag can be processed as an extended tag that may need to be changed at ingress / egress PE. The related NSPs of a GE-PW can be configured to identify the I-tag (using the Ethernet type assigned by [802.1ah]) and to change different I-tag fields, for example the 24 bits ISID or the QoS information as required. Alternatively the NSP capability code point 002 can be used to indicate the required rewrite of the I-tag fields for an out-NSP that can not perform this sort of processing. The parameter value of the code point 002 will specify the Ethernet type for I-tag [802.1ah]. The GE-PW (in-PW or out-PW) termination functions will not need to change to accommodate this new type of service. The required PW encapsulation described in the previous sections will be added before the PBB Backbone MAC header. For example assuming the PE depicted in Figure 1 [RFC4448] is connected to a PBB network (PBBN) and the I-tag field is used to defined the AC. +------------------------------------------+ | PE | +---+ +-+ +-----+ +------+ +------+ +-+ | | |P| | | |PW ter| | PSN | |P| | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN | | |y| | | |on | | | |y| | P | +-+ +-----+ +------+ +------+ +-+ | B | | | | B | +-+ +-----+ +------+ +------+ +-+ | N | |P| | | |PW ter| | PSN | |P| | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN | | |y| | | |on | | | |y| +---+ +-+ +-----+ +------+ +------+ +-+ | | +------------------------------------------+ Figure 1: PBB/PW The ingress PE may be configured to check on the incoming PBB packets the ISID value of the I-tag to determine the AC and subsequently the ingress NSP. The ingress NSP may be configured to change the values of different I-tag fields (for example the ISID, PCP, DEI bits). V. Kompella Expires January 2009 [Page 10] Internet-Draft Generalized Ethernet Pseudowire July 2008 Next the GE-PW termination functions will handle the PW header that will transport it throughout the PSN core and towards the egress NSP. The egress NSP may perform different functions depending on the type of egress AC: e.g. - if the access network is part of a different PBB service domain it may re-write the I-tag field. - if the access domain is a QinQ domain it may remove the PBB header altogether assuming it supports this capability. 7.5. PBB-VPLS Applicability The GE-PWs can be also applied to provide the interconnect between PBB-VPLS entities as described in [PBB-VPLS]. On top of the I-tag identification, processing functions described in the previous section, the related NSPs can emulate the PBB components described in [802.1ah], for example the Backbone (B) and Customer (I) components. For example, in a PBB-VPLS PE, as the In-NSP function receive the packet on the local AC, it may remove (default behavior) the service tags configured locally for each AC identification. Then it performs the Customer MAC switching and possibly the mapping to the Backbone MAC address specific to the I-component [802.1ah]. Subsequently the same In-NSP function will perform the Backbone MAC switching function characteristic to the B-component [802.1ah]. If the packet is to be transported over the PW infrastructure it will be handled to the in-PW function as per [PBB-VPLS]. From now on the processing steps described in the previous sections for various types of PW behaviors apply. Same for the Out-PW termination function in the other PE. The PW service label is used by the Out-PW function to identify the Out-NSP to which the packet is handled. There are two possibilities for the Out-NSP. If the PE is the final termination point for PBB, the Out-NSP runs both I and B components (PBB BEB node in [802.1ah]). It will handle first the Ethernet switching functions for Backbone MAC header followed by the switching functions for Customer MAC header. As the packet is handled to the egress AC the regular AC processing functions described in the previous sections apply. As a default behavior the out-NSP will add the service tags configured locally for AC identification. If an HVPLS architecture is used the next PE in the chain may be just an intermediate switching point for Backbone MAC header. The related Out-NSP function runs just the PBB B-component (PBB BCB node in [802.1ah]). It will handle just the Ethernet switching functions for Backbone MAC header. The possible results may be switching the packet back to another In-PW function for further forwarding towards the PBB-VPLS PE (PBB BEB). V. Kompella Expires January 2009 [Page 11] Internet-Draft Generalized Ethernet Pseudowire July 2008 [PBB-VPLS] and [PBB-Interop] describe the requirements, interoperability and solution in detail. Other applications are possible and require just the definition of the required NSP functions. 8. Management Model There will be a new object to describe the NSP compatibility capabilities [PW MIB]. 9. Acknowledgements The authors gratefully acknowledge the contributions of Nabil Bitar, and Dimitri Papadimitriou. 10. References Normative References [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [IANA PWE3] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4385] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC4720] Malis, A., Allan, D.,and N. Del Regno, "Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 4720, November 2006 [802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", December 7, 2005 [802.1ah] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", Work in Progress, March 26, 2008 V. Kompella Expires January 2009 [Page 12] Internet-Draft Generalized Ethernet Pseudowire July 2008 [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [PW MIB] T. Nadeau, and D. Zelig "Pseudowire (PW) Management Information Base (MIB)", draft-ietf-pwe3-pw-mib-14.txt, January 2008 ( work in progress ). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [PBB-VPLS] F. Balus, et Al. "VPLS Extensions for Provider Backbone Bridging", draft-balus-l2vpn-vpls-802.1ah-03.txt, February 2008 ( work in progress ). [PBB-Interop] A. Sajassi, et Al. "VPLS Interoperability with Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop- 03.txt, November 2007 ( work in progress ). 11. Security Considerations No new security issues arise out of the extensions proposed here. 12. IANA Considerations A new IANA allocation is required to describe NSP compatibility capabilities. 13. Authors' Addresses Andrew Malis Verizon andrew.g.malis@verizon.com Giles Heron British Telecom giles.heron@bt.com Shane Amante Level 3 V. Kompella Expires January 2009 [Page 13] Internet-Draft Generalized Ethernet Pseudowire July 2008 shane@castlepoint.net Vach Kompella Alcatel-Lucent vach.kompella@alcatel-lucent.com Florin Balus Alcatel-Lucent florin.balus@alcatel-lucent.com 14. Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 15. Intellectual Property 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. V. Kompella Expires January 2009 [Page 14] Internet-Draft Generalized Ethernet Pseudowire July 2008 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. 16. Acknowledgments Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). V. Kompella Expires January 2009 [Page 15]