Network Working Group Y (J) Stein Internet-Draft RAD Data Communications Expires: April 15, 2003 October 15, 2002 The PWE3 Control Word draft-stein-pwe3-controlword-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 on April 1, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Control words are used by PWE3 service emulations to carry information needed by the PWE3 Encapsulation Layer and the PSN Convergence Layer. The generic PWE3 documents do not specify the format of this control word and hence contradictory control word formats have proliferated in the various service encapsulation documents. We present an analysis of these control words and a suggestion for a single unified control word family. Stein Expires April 1, 2003 [Page 1] Internet-Draft PWE3-CW October 2002 1. Introduction The PWE3 framework document [FW] states that the encapsulation layer contains information regarding sequencing (which is optional), length (which is payload/PSN-specific) and timing information (once again depending on the payload). With the exception of timing, which is handled by RTP, this information is commonly contained in a control word, alternatively known as a PW header. The protocol layering document [PLD] sheds further light on the characteristics of the control word, at least when the underlying PSN is MPLS. It states that "a control word is used to carry most of the information needed by the PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact format. The flags in the control word provide the necessary payload convergence. A sequence field provides support for both in-order payload delivery and (supported by fragmentation control bits) a PSN fragmentation service within the PSN Convergence Layer. To allow PWE3 carried in MPLS to correctly pass over an Ethernet data-link, a length correction field is needed in the control word." From the above quotations we can infer that the control word should contain at least the following fields: sequence number, payload dependent flags, fragmentation indication bits, length. Specific payload types may require further fields as well. At least one control word that has been suggested contains a payload type identifier, as will be discussed in Section 5 below. 2. Formats in Present Drafts Figure 11 of the protocol layering document [PLD] roughly depicts the control word as follows. +-------+----+-----+------+ | Flags |Frag| Len |Seq # | +-------+----+-----+------+ Stein Expires April 1, 2003 [Page 2] Internet-Draft PWE3-CW October 2002 Unfortunately this is not sufficiently detailed to be taken as a complete format specification, and hence different control word formats have proliferated in the various service encapsulation documents. In fact, three families of control words have evolved, the only commonality being that all consist of 32 bit double-words (although one family leaves open the possibility of an extended format containing 64 bits). The Martini encapsulation schemes (e.g. [martiniATM], [martiniFR] and [martiniL2]) specify the following control word, which may be required or optional depending on details of the emulated service. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | FLAGS |0 0| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The initial four bits are reserved and must be set to zero; they may be used by implementations to ensure that the control word, rather than some other header, has been found. The four flags are protocol specific and are beyond the scope of our discussion. The length was originally 8 bits, but was later reduced to 6 bits leaving behind the two reserved zeros. The 16 bit sequence number is optional, and a zero value denotes that it is not used; see Section 3 infra. For the purposes of our discussion, it is useful to view the Martini control word as consisting of three fields. A 16-bit sequence number which is aligned on a 16-bit boundary; a single byte length field (restricted to values less than 64), aligned on a byte boundary, and one byte of application-dependent flags, aligned to a byte boundary. This last field may be separated into two sub-fields, each of four bits and aligned on 4-bit boundaries. When viewed in this fashion the field sizes are conventional and the alignments are in keeping with standard IETF practice. This same control word has been adopted by other drafts as well. [soETH] quotes this control word verbatim, while [ETH] uses 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which is a special case of the above for which flags and length are not required. Stein Expires April 1, 2003 [Page 3] Internet-Draft PWE3-CW October 2002 Early versions of [anaviTDM] specified 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SEQNUM | FORMID |FLAGS| RES | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with an eight bit sequence number, a 5 bit payload type, and 3 flag bits. This was subsequently changed to 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FORMID | FLAGS |0 0| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in order to better conform to the Martini format. The only remaining discrepancy relates to payload type identifier which overwrites the initial reserved field in the Martini word (see Section 5 below). Other ATM drafts, such as [brayleyATM] and [rutemillerATM], dictate the use of 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which is also a Martini-like word, with the initial reserved field entirely occupied by flags. Finally, [kamapabhavaFR], which was later absorbed into [martiniFR], originally defined the following FRoPW header 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | FLAGS | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which is the Martini control word except that more flags were defined at the expense of reserved bits. Stein Expires April 1, 2003 [Page 4] Internet-Draft PWE3-CW October 2002 The [SONET] and [SONET-VT] drafts define a second family, which they denote the "CEP header". 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| FLAGS | Structure Pointer | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The E bit presently MUST be set to zero in these drafts, but is the precursor of an extended control word. The 13 bit structure pointer is specific to these two drafts, while the sequence number is restricted to only 14 bits in order to accommodate this pointer. If RTP is used sequence number MUST match the LSBs of the 16 bit RTP sequence number. Regrettably, due to having to fit in the structure pointer, the CEP header employs awkward field sizes (13 and 14 bits for the pointer and sequence number, respectively) and unwieldy alignments. In addition, the E-bit dependent extension, if ever employed, may be troublesome for some implementations. [vainshteinTDM] uses essentially the same control word except that the unneeded structure pointer field is replaced by a reserved field, and the precise meanings of the flags is somewhat different. The third family of control words is represented in such ATM drafts as [bocciATM], [fisherATM] and [koleyniATM] and in a related TDM draft [davariTDM]. We shall call it the Fischer control word, and it has the following structure. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Sequence Number | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The single byte length field and the two byte sequence number are both optional. Where the eight bits marked here as flags are spelled out, there are either four true flags, two reserved bits and two fragmentation indicator bits, or three flags, two reserved bits and a three bit payload type identifier. To summarize this section, the most popular control word family is the Martini one, shared by a wide spectrum of frame-relay, ATM, ethernet and TDM drafts. This is followed by the CEP header tendered by three allied TDM drafts. The Fischer word is proffered only by a set of related ATM drafts. Stein Expires April 1, 2003 [Page 5] Internet-Draft PWE3-CW October 2002 3. Sequence Number The protocol layering document [PLD] states "when packets carrying the PW-PDUs traverse a PSN, they may arrive out of order at the destination PE. For some services, the frames (control frames, data frames, or both control and data frames) must be delivered in order. For such services, some mechanism must be provided for ensuring in- order delivery. Providing a sequence number in the sequence sub- layer header for each packet is one possible approach to out-of- sequence detection." In addition to the reordering of out-of-order packets, sequence numbers are often used to detect that packets have been lost. The question arises as to how extensive this reordering and packet loss detection has to be. For example, if a packet arives after one or two later packets have already been received, one could legitimately expect the mechanism employing the sequence numbers to seamlessly reorder the packets; but is it is worthwhile to demand immaculate reodering of a packet that has been delayed by 10,000 packets? Similarly, timing reconstruction for real-time traffic can take advantage of the knowledge of the number of packets lost when this number is small; but when the large number of lost packets signifies that the link has fallen, can such information be used to any avail? One way of dealing with these questions is to consider the sequence number to be merely an indication of delayed or lost packets, rather than a panacea for all such network maladies. For example, a packet that is inordinately delayed will probably be discarded when it finally arrives, and some higher layer mechanism should be used to compensate for this loss. As another example, the effects of extremely infrequent events, such as fiber cuts, should not be expected to be completely offset by sequence number dependent mechanisms alone. How many bits need the sequence number contain? While TCP provides a 32 bit sequence number for the initial octet of a packet, RTP furnishes a 16 bit sequence number for the packet, AAL1 uses only three bits (a period of only eight) and AAL2 manages with a single bit sequence number. According to the above reasoning, the size of the sequence number must be chosen to accommodate the maximum number of packets by which a packet may be delayed and for which we are still required to seamlessly re-order, or the number of successive lost packets with which we are required to cope. It has been argued that the underlying PSN to be used for PWE3 services should have very low Stein Expires April 1, 2003 [Page 6] Internet-Draft PWE3-CW October 2002 packet loss (under one percent), and that packet re-order events are very rare. Even assuming a higher percentage and extremely bursty packet loss, the probability under non-catastrophic circumstances of more than 100 successive lost packets is negligible. Hence, the number of required sequence number bits can be kept small, perhaps six to eight bits being enough. In light of this reasoning, the rationale for the 14 or 16 bit sequence numbers used in most drafts is questionable. Some protocols, notably AAL1, protect the sequence number by an error detection code. In the PWE3 case, the probability of a packet being delivered with a corrupted sequence number is very low, and this protection is not needed. In those cases where RTP is used to transport timing, its 16 bit mandatory sequence number appears in the packet header. The question arises as to the relationship between these two sequence numbers. There are basically three possibilities: no relationship (i.e. two complete independent sequence numbers are employed), linking the sequence numbers (e.g. by making the control word sequence number equal the LSBs of the RTP sequence number), or omitting the redundant control word sequence number. The first option has not been suggested, but the other two have both been proposed, the Martini control word omitting its sequence number, while the CEP control word defines linkage. Drafts utilizing the Fischer control word do not allude to the use of RTP. Another question relates to the generation procedure. Most sequence numbers are treated simply as unsigned integers that return to zero after reaching their maximum value. An exception to this principle is found in the Martini and Fischer optional sequence numbers where a zero sequence number value is taken to mean that sequencing is not employed. Since zero is unavailable when the sequence number cycles through all the possible values, after attaining maximum value these sequence numbers reset to one and not to zero. This mechanism of avoiding zero sequence numbers is imcompatible with linkage to RTP sequence numbers, since the LSBs of the RTP sequence number will unavoidably attain zero values. Stein Expires April 1, 2003 [Page 7] Internet-Draft PWE3-CW October 2002 4. Flags Most PWE3 service documents stipulate that various flags are to be used for signaling between edge devices. Some of these flags are not indispensable, but their omission would necessitate parsing of payload data by the edge devices. Others are needed in order to emulate similar functionality in the native service. The ethernet draft [ETH] does not specify any flags, the TDMoIP [anaviTDM] draft specifies two, the [SONET], [SONET-VT] and CESoPSN [vainshteinTDM] drafts as well as the Martini encapsulation schemes ([martiniATM], [martiniFR] and [martiniL2]) require four, [kamapabhavaFR] reserved 7 bits, and the Fischer control word sets aside a full byte, although not all of it is utilized. 5. Payload Type The TDMoIP [anaviTDM] draft incorporates a four bit payload type indication (earlier versions of this draft devoted five bits to this quantity. Since the payload type should not change during the lifetime of the tunnel, this information can be specified during setup and need not be carried in the per-packet header. However, many protocols embrace such payload type codes, which are useful as sanity checks, and for packet identification by passive protocol analysis equipment. The layer 2 frames transport control protocol document [CTL] defines the concept of a payload type as "a 15 bit quantity containing a value which represents the type of VC" and assigns values for frame relay, ATM AAL5 VCC transport, ATM transparent cell transport, Ethernet VLAN, Ethernet, HDLC, PPP, circuit emulation, ATM VCC cell transport and ATM VPC cell transport. This 15 bit quantity is specified via LDP during tunnel setup, and is not carried thereafter. It is not clear why the aforementioned payload type is allotted 15 bits, indeed only five of these bits are actually used. Also the numbering scheme employed seems to be completely arbitrary. A more sensible approach would be to assign eight bit payload type codes, four bits of which (MSBs) designate the major service type, with the remaining four bits (LSBs) determining more detailed aspects of the emulation. For example, one may use for the high order bits the following codes: Stein Expires April 1, 2003 [Page 8] Internet-Draft PWE3-CW October 2002 0001 Ethernet 0010 frame relay 0100 ATM 1000 SONET 1001 TDM while the low order bits for ATM may be 0001 cell mode 0010 AAL5 PDU mode 0011 AAL5 SDU mode 0100 transparent cell transport 0101 VCC cell transport 0110 VPC cell transport 1000 port mode and for TDM they may be the FORMID specified in [anaviTDM]. An advantage of this suggestion is that the full eight bits may be disseminated during setup, while in order to economize only the low order four bits may be optionally used on a per packet basis. When these bits are suppressed the relevant field must be set to zero. 6. Length The requirements document [REQ] says "A PWE3 approach MUST accommodate variable length PDUs, if variable length PDUs are allowed by the native service. For example, a PWE3 approach for Frame Relay MUST accommodate variable length frames." In order to accomodate this requirement a length indicator may be used. Such an indicator is only mandatory when the service emulation produces variable length packets and the minimum packet length is less than the MTU transported by the underlying PSN. The most prevalent case is ethernet with an MTU of 64 bytes, imposing a six- bit length field. In such cases the underlying PSN will add a variable number of padding bytes, and it is desirable to remove this padding when the packet reaches the destination edge. When the packet length (which we define as the length of the payload plus the length of the control word), is less than the MTU the length field is set to this packet length, otherwise it is set to zero. While in the past some drafts have contained eight bit length fields, present proposals all include six bit fields. Stein Expires April 1, 2003 [Page 9] Internet-Draft PWE3-CW October 2002 7. Suggestions As we saw above in Section 2 there are a plethora of competing proposals for CWs, and a compromise proposal for the ATM issue is suggesting different control word families depending on mode. This state of affairs is impeding progress, and if not amended will lead to an incoherent set of PWE standards. In this section I will show that a single control word family for all PWE services is possible. The purpose of this proposal is to kick-off serious discussion of the control word issue. Basing ourselves on the popular Martini control word we suggest the following scheme. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | FLAGS | Length | Seq # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The initial reserved field is set to zero. Note that there is no possibility of extended format and hence no E bit. All fields are one byte in length, consistent with the reasoning of the previous sections. The placement of the various fields is consistent with standard IETF practice of aligning bytes on byte boundaries. The sequence number should cycle through all values including zero. If a mechanism is needed to indicate that sequencing is not being used, then one of the six middle reserved bits may be used for this purpose. If RTP is employed then linkage may be used. If it is desired to indicate the payload type, this is done by using either of the reserved fields to contain the four low order bits of the code suggested in Section 5, which is consistent since the FORMID is zero when not used. For the SONET drafts which require a pointer but have fewer flags and do not use a length, a modification is required. An awkward but econmical possibility is 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | FLAGS | POINTER | Seq # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ but it would be cleaner to utilize an extended format control word. Stein Expires April 1, 2003 [Page 10] Internet-Draft PWE3-CW October 2002 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | FLAGS | POINTER | Seq # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POINTER | RES | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above unification is achievable due to the short sequence number. If, despite the reasoning of Section 3, it is concluded that a longer sequence number is needed, an alternative family is possible. The basic word for this case will be 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | FLAGS | Length | Seq # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with a 14-bit sequence number. If the payload type is desired, it will overwrite the initial reserved field. Here the pointer needed in the SONET drafts absolutely necessitates the extended format, 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | FLAGS | Length | Seq # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POINTER | RES | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ but no E_bit indication is needed. 8. Acknowledgement I would like to thank Stewart Bryant for a useful exchange of ideas regarding the use of sequence numbers, and field alignment. Stein Expires April 1, 2003 [Page 11] Internet-Draft PWE3-CW October 2002 9. References [anaviTDM] TDM over IP (work in progress) draft-anavi-tdmoip-04.txt, Yaakov (Jonathan) Stein et al [bocciATM] Applicability Statement for AAL5 Transparent Frame Encapsulation over PSN (work in progress) draft-bocci-pwe3-app-frame- over-psn-00.txt, Matthew Bocci et al [brayleyATM] PWE3: ATM service description (work in progress) draft- brayley-pwe3-atm-service-01.txt, Jeremy Brayley et al [CTL] Transport of Layer 2 Frames Over MPLS (work in progress) draft- ietf-pwe3-control-protocol-00.txt, Luca Martini et al [davariTDM] Transport of ATM AAL1/2 frames over PSN (work in progress) draft-davari-pwe3-aal12-over-psn-00.txt, Shahram Davari [ETH] Encapsulation Methods for Transport of Ethernet Frames Over IP/ MPLS Networks (work in progress) draft-ietf-pwe3-ethernet-encap- 00.txt, Luca Martini et al [fischerATM] PWE3: ATM service description (work in progress) draft- fischer-pwe3-atm-service-03.txt, John Fischer et al [FW] Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) (work in progress) draft-ietf-pwe3-framework-00.txt, Prayson Pate et al [kamapabhavaFR] Frame Relay Transport and Encapsulation over Pseudo- Wires (work in progress) draft-kamapabhava-fr-pwe3-01.txt, Claude Kawa et al [koleyniATM] Applicability Statement for ATM Cell Encapsulation over PSN (work in progress) draft-koleyni-pwe3-app-cell-over-psn-01.txt, Ghassem Koleyni et al [martiniATM] Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks (work in progress) draft-martini-atm-encap- mpls-01.txt, Luca Martini et al [martiniFR] Frame Relay Encapsulation over Pseudo-Wires (work in progress) draft-martini-frame-encap-mpls-01.txt, Claude Kawa et al [martiniL2] Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks (work in progress) draft-martini-l2circuit- encap-mpls-04.txt, Luca Martini et al Stein Expires April 1, 2003 [Page 12] Internet-Draft PWE3-CW October 2002 [PLD] Protocol Layering in PWE3 (work in progress) draft-bryant-pwe3- protocol-layer-01.txt, Stewart Bryant et al [REQ] Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) (work in progress) draft-ietf-pwe3-requirements-02.txt, XiPeng Xiao et al [rutemillerATM] PWE3: ATM Cell Encapsulation (work in progress) draft-rutemiller-pwe3-atm-encaps-00.txt, John Rutemiller et al [soETH] Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3) (work in progress) draft-so-pwe3-ethernet.txt, Tricci So et al [SONET] TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3) (work in progress) draft-ietf-pwe3-sonet-00.txt, Andrew G. Malis et al [SONET-VT] TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3), (work in progress) draft-ietf-pwe3-sonet-vt-00.txt, Prayson Pate et al [vainshteinTDM] TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) (work in progress) draft-vainshtein-cesopsn-03.txt, Alexander ("Sasha") Vainshtein et al Author's Address Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenburg St., Bldg C Tel Aviv 69719 ISRAEL Phone: +972 3 6455389 EMail: yaakov_s@rad.co.il Stein Expires April 1, 2003 [Page 13] Internet-Draft PWE3-CW October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stein Expires April 1, 2003 [Page 14]