idnits 2.17.1 draft-stein-pwe3-pwce2e-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2003) is 7487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-arch-06 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'PWE-arch') == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-04 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Y(J) Stein 3 Internet-Draft RAD Data Communications 4 Expires: April 19, 2004 October 20, 2003 6 Pseudowire Customer Edge to Customer Edge Emulation 7 draft-stein-pwe3-pwce2e-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 19, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The PWE3 architecture document places the interworking function 39 solely in the PE, so that the attachment circuit between PE and CE 40 carries the native service. This is appropriate for a service 41 provider that offers the customer a seamless alternative for 42 transporting the native service. An alternative is to place the 43 interworking function in the CE, with ethernet access from CE to PE. 44 We present advantages of this approach and note required changes to 45 the PWE architecture. 47 1. Introduction 49 In VPN architectures provider edge routers communicate with customer 50 edge routers, and both types of routers carry essentially the same 51 service (e.g. IP). The PWE model is an extension of this 52 architecture, but while the provider has a IP or MPLS packet switched 53 network, the customer's network is some native service, e.g. ATM, 54 frame-relay, or TDM. In order to transport the customer's traffic 55 over the provider's PSN, an interworking function is required. The 56 PWE architecture as detailed in [PWE-arch] places this interworking 57 function in the PE. The emulation of the native service is thus 58 "edge to edge", meaning provider edge to provider edge. We can call 59 this pseudowire provider edge to provider edge emulation, or PWPE2E. 61 The reasoning behind this placement of the interworking function is 62 clear. The customer is assumed to have had a native service 63 provider, and to have connected to this provider via a native service 64 attachment circuit. Hence the new service provider deploying a PWE 65 network and wishing to provide a seamless migration path, naturally 66 offers to accept the native service attachment circuit. In this way 67 no modification of the customer premises equipment is required, and 68 the customer may even be unaware of the different transport mode of 69 the new provider. 71 However, this is not the only possible placement of the interworking 72 function. For reasons discussed in Section 2 below, it is frequently 73 more sensible to place the interworking function at the CE instead. 74 In that case the CE to PE connection is of the PSN type, rather than 75 of the native service, and the emulation is from CE to CE. With can 76 thus call this variant pseudowire customer edge to customer edge 77 emulation, or PWCE2E. 79 Although the traffic type of the attachment circuit tends to 80 distinguish between PWPE2E and PWCE2E, this differentiation is not 81 sufficient. In a possible scenario the interworking function itself, 82 although located at the customer's site, is under control of the 83 provider. In this case it essentially functions as a user located 84 PE, and participates in provider network signaling. In the true 85 PWCE2E case the interworking function belongs to the customer, and 86 the provider may be unaware of its existence. All provider network 87 signaling is carried out at the remote PE, as in the standard PWE 88 model [PWE-ctrl]. 90 A provider may offer both PWPE2E and PWCE2E connections. A single 91 end to end emulation may be PWPE2E on one side and PWCE2E on the 92 other. 94 2. Motivations for PWCE2E 96 Why should the interworking be performed before the attachment 97 circuit? There are various reasons. 99 The first is to take advantage of ethernet access. Ethernet access 100 is becoming widely available and may prove less expensive to the 101 customer than ATM or frame relay access links. Standardization of 102 ethernet in the first mile and metro ethernet networks is being 103 advanced by several forums, and the models being developed in these 104 forums are tbus different from the PWE model. Ethernet access may 105 particularly appeal to customers who did not previously contract with 106 service providers for their non-ethernet services. 108 In the PWPE2E model the interworking function tends to be a large 109 gateway, built to serve large numbers of customers. It may not be 110 viable for a provider to install a large gateway when only a few 111 customers are interested in a particular service. In such cases a 112 small customer located gateway may be desirable. 114 An advantage of the PWCE2E model is that customer edge to customer 115 edge OAM and performance measurement is natural here, while the 116 parallel functionalities for the PWPE2E case cover only the provider 117 network, and not the attachment circuits. 119 3. Implications 121 When the PSN is IP, no user protocol enhancements are required for 122 PWCE2E. The IP header, demultiplexing label, control word, and 123 payload are sent from CE to PE as described in the present service 124 specific encapsulation documents. 126 For the MPLS case, IP access is also possible, with the CE converting 127 the native service into IP packets. The PE then prepends MPLS labels 128 and the packet is forwarded as any other MPLS-labeled IP packet. 129 This would result in inefficient transport, and circumvents the PWE 130 mechanisms for MPLS. 132 The ideal way of handling a PWCE2E packet is to have the CE perform 133 the service specific encapsulation and to prepend the (inner) PW 134 label, but no (outer) MPLS transport labels. The PE, which 135 participates in the provider network signaling, then adds the 136 appropriate MPLS labels as required. 138 This capability of accepting non-IP MPLS-like packets is not 139 presently available in MPLS LERs nor in PWE PEs. Its advantage is 140 its universality. Equipped with this feature any edge router can 141 participate in PWE applications without being aware of service 142 specific details. 144 Other than defining this capability, only minor changes to the 145 present PWE documents are needed to add PWCE2E functionality. Figure 146 2 of the architecture document (PWE3 Network Reference Model) would 147 need to be slightly enhanced, and the term "CE-bound" would need to 148 be changed. 150 4. References 152 [PWE-arch] draft-ietf-pwe3-arch-06.txt (2003) PWE3 Architecture, S. 153 Bryant, P. Pate, work in progress 155 [PWE-ctrl] draft-ietf-pwe3-control-protocol-04.txt (2003) Pseudowire 156 Setup and Maintenance using LDP, L. Martini et al, work in progress 158 Author's Address 160 Yaakov (Jonathan) Stein 161 RAD Data Communications 162 24 Raoul Wallenberg St., Bldg C 163 Tel Aviv 69719 164 ISRAEL 166 Phone: +972 3 6455389 167 EMail: yaakov_s@rad.com 169 Full Copyright Statement 171 Copyright (C) The Internet Society (2003). All Rights Reserved. 173 This document and translations of it may be copied and furnished to 174 others, and derivative works that comment on or otherwise explain it 175 or assist in its implementation may be prepared, copied, published 176 and distributed, in whole or in part, without restriction of any 177 kind, provided that the above copyright notice and this paragraph are 178 included on all such copies and derivative works. However, this 179 document itself may not be modified in any way, such as by removing 180 the copyright notice or references to the Internet Society or other 181 Internet organizations, except as needed for the purpose of 182 developing Internet standards in which case the procedures for 183 copyrights defined in the Internet Standards process must be 184 followed, or as required to translate it into languages other than 185 English. 187 The limited permissions granted above are perpetual and will not be 188 revoked by the Internet Society or its successors or assigns. 190 This document and the information contained herein is provided on an 191 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 192 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 193 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 194 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 195 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 197 Acknowledgement 199 Funding for the RFC Editor function is currently provided by the 200 Internet Society.